Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

ralphmorris's avatar

Validating Current Team if user were to change teams in a different tab

I've come across a scenario where users might change teams in another tab, but then come back to the original tab and create a post for instance. This would then be assigned the the wrong team accidentally if you were simply doing the below:

$post = auth()->user()->currentTeam->posts()->create($request->all());

What might be the best/most manageable way of validating that the user is still on the same team as when they first loaded the page for example? Some sort of team_token input in every single form? or something else?

Thanks!

0 likes
10 replies
ralphmorris's avatar

Thanks @Cruorzy, I'm using policies in there to check if the user is part of the team, however this would always return true unless it was a malicious user trying to access a page belonging to a team they weren't on even if the current_team_id has changed as it is a difference relationship.

However I need to check the current_team_id matches the id that the user was currently on when they first loaded the page. The only thing I can think of is a team token in a hidden input but this feels a bit much for every single form.

For instance if I had a route of /posts, there is no team identifier in the url to check the current_team_id against, so it would just create the post against the current_team_id even if it has changed when the user was on another page. As opposed to /{team}/posts where you can validate the team. However this kind of defeats the point of the having the current_team_id.

Hope that makes sense.

Cruorzy's avatar

Back to the first post here, I think I was thinking wrongly about your issue. Is it correct that if the user switched teams and goes back to the page that was opened and saves the post. the post becomes part of the new team he just joined before making the post?

ralphmorris's avatar

Hi @Cruorzy , no worries. Yes that's what happens. But the user would likely think they are still on the old teams page when creating a post for example as the logo (or whatever) would be the original teams. Obviously if the user refreshed the page it would show the updated current teams logo so would be more obvious but I doubt a user would remember to do that.

Cruorzy's avatar

Well what you could do is when you set a new current_team_id also update a new field named last_team_change with a dateTime

Then in the store method

if (\Carbon\Carbon::now < $user->last_team_change) {
    //throw error
}

It's still not fully clean but this is how I would solve it since can't think of anything better.

martinbean's avatar

@RALPHMORRIS The POST request in the first time to create a new post should occur after the user’s switched teams in the second time. Therefore, the POST request should create a post against the team the user has selected. If not, then you have some logical error somewhere.

mac03733's avatar

why not check if the user belongs to the team they are trying to post under " in the the create post method". or am i not getting the question

Cruorzy's avatar

@mac03733 Took me a bit to understand but if you read the question you can tell that wouldn't help since it will return true.

@martinbean He doesn't include the team in the url there is no way to know what page he is actually on, the asier way would be to indeed add a id or slug to the url to identify. But if he really doesn't want to I think my solution would do the job for him.

He can't simply add a new reply when the team has been switched and you are still on the old team page.

ralphmorris's avatar

Thanks guys, for all your input.

@Cruorzy I believe you are correct although I think the Carbon::now() would need to be done on the original page load and put into the form so you could check whether the user had switched teams since loading the current page rather than in the store method.

Something like:

if (request()->page_original_loaded_timestamp < $user->last_team_change) {
    //throw error
}
Cruorzy's avatar
Cruorzy
Best Answer
Level 14

@ralphmorris You've got a point there, it ain't my brightest today. Personally I would make a unique identifier has instead of a dateTime since they can just up the date and work around it. Which seems useless but still possible.

But then you would come close to your "token" idea.

Please or to participate in this conversation.