I am not a superb developer, so I guess the problem I did run into is just to big for me.
I have a project where I have different subdomains for the current language. When I login a user it is logged only for the current subdomain. So when I login at "en.Aproject.com", and then go to "de.Aproject.com", the user will not be logged in. They don't share the session. I already tried to modify the 'domain' => null, in app/sessions.php. But when I change the value here the Login doesn't work at all. Then everytime a new Session-row is created in the DB and Laravel seems not to recognize them.
Is the current domain saved somehow in the session identifier? Is it possible to use one session for different domains? I found some stuff about OAuth and Single sign-on but I can not handle it by myself.
I was thinking about (when logging in and the credentials are correct) calling a script via Ajax, which should log in the user for all needed domains. But I would have to do the same for logging out.. And I will probably have a lot of domains. The project will have one base page and several subprojects (all with the different languages). Like this
mainproject.com
en.mainproject.com
de.mainproject.com
...
Aproject.com
en.Aproject.com
de.Aproject.com
...
Bproject.com
en.Bproject.com
de.Bproject.com
...
So it would just feel wrong to log in the user to like 20 different pages and create 20 sessions... It would feel better to just use one session for all of them.
Okay, I hope you understand the problem and someone already had the same problem and found a solution. Thanks!!!!!!!! greets. gerti
Background info.. I am using Laravel 4.2
Now I just tried something, maybe it helps someone. Actually point 2 is weird to me (see below)
I display these 3 things:
Session::getId()
Auth::getName()
var_dump(Session::all())
I display them on "de.Aproject.com". Here I am logged in.
And i display them on "en.Aproject.com"... Where I am still logged out (which I want to fix :D )
The value of Session::getId() is different on both sides. Thats the problem I guess, they should share the same.
The value of Auth::getName() is the same on both sides (login_82e5d2c56bdd0811318f0cf078b78bfc). Which I don't understand. Why does the second page have this value when i am not logged in?
The value of Session::all() is ["login_82e5d2c56bdd0811318f0cf078b78bfc"] => string(17) "test#test.de" on the first site, on the second its empty. Thats correct.
Since the default Laravel authentication system uses cookies to manage the session, you actually need to login the user on each subdomain you're going to use. To avoid that, you can use another session driver like database.
Related
I have two independent copies of a same Laravel app on my domain, each one behaves as expected when used exclusively:
app1.mydomain.com
app2.mydomain.com
They do have different APP_NAME values in their respective .env files. I do want the two to be completely independent (thus all of the rational env variables are set appropriately unique, e.g: the APP_KEYs, APP_NAMEs, APP_URLs, etc). While two distinct databases are designated (though on a same host, of course), I've put an identical "user" on both of the databases.
The thing is, sometimes when they're being utilized together (kinda concurrently), a 419 error shows up when I'm already logged into one of them through the "user" credentials, and try to log into the other one through a distinct but identical "user" credentials! Seems like the app2 thinks the user is already logged in; while the user is already logged into the other supposedly independent subdomain. I've tried SESSION_COOKIE and SESSION_DOMAIN environment variables to no avail.
By setting the SESSION_DOMAINs to app1.mydomain.com and app2.mydomain.com respectively; you may log into one of them successfully; but trying to log into the other one displays the error page of 419! Also, the domain entries for the session in the browser are set with a preceding dot, e.g: .app1.mydomain.com (while when you omit the SESSION_DOMAINs, the values do appear without the leading dot.)
I've noticed a session of app1_session does also show up in the browser cookies for app2.mydomain.com (and sometimes a session of laravel_session do also show up! the laravel is a default string substituted whenever the environment variable of APP_NAME is not read by the system!)
So, what's wrong and how can I fix it?!
Assuming you are setting up each .env file pointing to each separate sub domain. The functionality you may be after is setting the same_site value to strict.
This will ensure only cookies that are from the defined domain are accepted.
P.S. for good measure, a php artisan config:clear once you change it.
I think its not a Problem on Any of your subdomains Probably . I think You where checking out Both the site on same browser instance that why this issue is occuring try to use one on normal browser mode & open another on Private mode (or) Incognito mode ... it would probably works on your case ....
If it does not works for you Implement A Laravel Session Table So you can Track Session IDs of logged in user having a current session i hope it works for you
Same issue happening to me, fixed by setting different values for SESSION_COOKIE= inside each project .env
Before anyone tells me to Google it - I did and followed the instructions on this link:
https://medium.com/#zsolt.gyure96/how-to-share-sessions-between-two-laravel-applications-4b9d061fa599
Below is my setup: I have a group of sites that are all under the same domain hosted under different directories. I use virtual host aliasing to point them. For example, alias blog points to example.com/blog. Now, I would like to share the users and sessions among my apps. I followed the instructions in the above article and created a common_database that manages all the user data and sessions. My apps can read the sessions table. I also have the same session set up as my domain.
By adding
protected $connection = 'common_database';
in the following files I can login and register from example.com/blog/login or register routes.
vendor/laravel/ui/auth-backend/RegistersUsers.php
vendor/laravel/ui/auth-backend/AuthenticatesUsers.php Instead added
The only problem I have now is that there is no session sharing. For example if i login example.com/blog/login then I cannot use the same session for example.com or example.com/news. I have to re-login. What am I missing here?
SESSION_DRIVER was not set to the database in the main site's .env.
I don't know if it will work for you but what I did was instead of using SESSSION_DRIVER=database I used SESSSION_DRIVER=cookie on .env file make sure your APP_KEY is the same for both projects.
After a research it seems that Meteor Sessions are reset after refreshing page or opening the website in new tab, i.e. they are not usual server-side sessions but something like global javascript variables on client-side. Some people advice to use AmplifyJS, but I'm not sure that it will work like usual session in other frameworks/languages and also it is a third party library, so is there any normal way to use sessions in Meteor, i.e. keep user-specific data on server?
At this moment I'm handling that by using custom Collections, but it is not an ideal way of doing that because it is needed to remove expired values from Collection manually, which makes additional troubles.
Yes this is correct. Despite the name Session is nothing like a cookie, but just a reactive form of a variable stored in a hashmap
To keep data persistent across tabs you need to use a Collections (as this is the only way to reactively share data across tabs) - Cookies can't work because they can't be made reactive as data needs to be sent to the server to notify the client when there is a change. There really wouldn't be another way at the moment as the publish/subscribe methods can only send down data from collections at the moment.
You can use your setup you have now with your custom collection. You can use a server side cron job to remove expired data (either with Meteor.setInterval or Tom Coleman's cron.
There is a package developed just for that: https://atmospherejs.com/u2622/persistent-session
After installation you can use the following functions to set sessions which are persistent:
//store a persistent session variable which is stored across templates
Session.setPersistent(key, value);
//same as above, but automatically deletes session data when user logs out
Session.setAuth(key, value);
I've tried the package and it works like charm.
I have to create routes of the type /:username in an express application. I can think of two ways for this and i wonder which is more performance optimized. The first is to dynamic serve the route with a call to the db and if the username exists to serve the profile needed. The second one is to create a function, so that when a user is created his profile url is hardcoded into the app and then removed when a user is deleted. This way there won't be calls to the db whenever a url of this type is requested. So the question is what would be the performance problems in the second case, if any and what are the advantages and disadvantages on each case, mainly performance-wise?
Do the first one. I cannot speak towards performance (however I feel that the first will be faster in the long-run), however what happens if your application were to (not saying this would happen) be as popular as Facebook and you then have 1 000 000 000 routes in your express application? Even trying to start your app would get ridiculous.
Databases can handle this, and if you're really worried about it you could keep a cache of the usernames that have already been checked. Add them when you first check it, and delete them if the username is deleted.
It also occurs to me now; will you not have to perform pretty much the same query to get the information to populate the profile anyways? If you are suggesting to create static pages for each profile when the account is created, don't do this. This is what databases were designed for, so it is perfectly safe to use them in this way.
I simply use /:username and i have it below my other routes, so it doesnt' supersede other pages like /login
If there is no user for that username, then I redirect them to the homepage.
Using mongoose, you can do something like this:
//app.js
app.get('/:username', routes.profile.get);
//route handler
User.findOne({ username: req.params.username}, function(err, owner){
if ( !owner ) {
req.flash('error', 'Woops, looks like that account doesn\'t exist.');
res.redirect('/');
}
//do something with owner
});
I'm using a modified version of Felix Geisendörfer's SimpleAuth/SimpleAcl components that I've combined into a single Component, Simple_Authable.
I changed his startup() function to initialize() to not clutter the beforeFilter function in my app_controller.
One of the things that this component does is check who the active user is and if that user can't be found it either looks him up based on the primary User.id or uses 'guest'. Either way, the component uses $this->Controller->Session->write() to save the active user or guest information.
I'm also using Felix's Authsome plugin instead of the default CakePHP Auth component.
When I'm logging in, the active user is guest, obviously.
After I've submitted the form, the active user is still guest because the component's initialize() function is firing before everything else. Then, the Authsome plugin comes into play and validates my user as "root" and also calls $this->SimpleAuthable->setActiveUser($id, true); to force SimpleAuthable to update the active user information it is storing via $this->Controller->Session; Then I am redirected and my simple Session information and DebugKit's Session tab reflect that I am indeed the root user.
However, when I try to navigate to an 'admin' page, let's say /admin/users/index, lo and behold SimpleAuthable thinks I'm still a 'guest' user because when it performs a $this->Controller->Session->read() call to the key holding my user id, it is getting an empty response, i.e., the data stored on the previous page didn't persist.
Maybe there is something funky happening between Authsome & SimpleAuthable, but things look pretty straightforward and to my mind, $this->Controller->Session should be saving and persisting the data written to it.
So, I'm looking at refactoring all the calls to $this->Controller->Session and replacing them with $this->Session but first I wanted to throw this out to the community and see if anybody has seen anything similar and if so how did they resolve it.
Sincerely,
Christopher.
I found the problem... I'm also using Joshua McNeese's Permissionable plugin and I needed to disable it for the $this->Controller->{$this->userModel}->findById($id); in my SimpleAuthable component when I try to lookup the current active user.
Note to self: I would have caught this faster if I had some unit testing in place :(.