Programmatically login on subdomain without sharing the session

@piljac1 Just login with remember and it will work.

https://laravel.com/docs/7.x/authentication#remembering-users

How would that solve my problem ? Explain please :)

That, what I know it's not possible what you want.

That's what I thought, but I'll leave the thread open to see if somebody out there has an enlightening idea.

For now, we brainstormed and decided to go with a short expiry signed route which injects a session variable to the frontend domain. It's not logging in the backend user in the frontend, but it works for our specific use case.

I would have however preferred a possible login solution, so we'll see what happens with this thread :P

The cookie is by default using the APP_NAME or config(app.name,"Laravel") You could do a dynamic change on the cookie name generation per domain.

default: laravel_session_hash or yourAppName_session_hash

I used (sub)domain_session_hash and works just fine

Simply checking the Request->getHost() and change the cookie name in the config repo in a service provider or middleware that fires before 'web'.

Could you set the cookie domain to the parent domain? When the back end user logs in, give them a separate cookie which represents them in the backend.

When a user tries to access content for which they must be authenticated, the auth middleware runs.

You could adapt this to see if the user presented this backend cookie. If so, check their id and if ok, log them in.

You will need to ensure you set the app name so that session cookies are not confused.

Also watch mohammed said video regarding multi tenancy because a front end user could change the domain on their session cookie to gain access to the backend

https://m.youtube.com/watch?v=cjWEZ5SKvIY

I have to add that I also changed the token part of cookie naming which is hardcoded to self::static in laravel. Not sure if you can change a cookie though as Laravel invalidates tampered with cookies. Although changing to a valid value may work lol.

@artcore @snapey Thanks for your inputs guys ! Greatly appreciated ! Unfortunately, we have spent our timebox for this issue so we will have to stick with our work around, but I will gladly test your method when I encounter this problem in the future :)