When a user comes to our webset/webapp, we would like the user to be able to go around the site and do things as normal (currently the site consists of almost exclusively CRUD operations). That way the user can see what the site has to offer by DOING, before logging in.
We want to store all these operations in a session or temporarily in SQLAlchemy operations but not commited to the database.
Then, we'd like it if when the user creates an account or logs in, all those operations are done under that account name.
What is a good way to do this? Currently all our server-side functionality automatically does a SQLAlchemy commit after successful database operations. So I'm not sure if removing that and doing commits manually would be a good idea.
On the other hand, saving database operations in a session/cookie seems bad as well. Then we need to fake the database in cookies, which is ugly and a lot of work.
Note that we are using postgreSQL.
I think the best way would be to assign a temporary username to every user that visits the site & store that information in a SESSION cookie along with everything else they do while there. Then when they signup, you can move all those SESSION var's into the DB under their new username.
BTW, there's nothing wrong with saving anything in SESSION cookies, as long as you're using HTTPS (and it sounds like you should be using that for the site you've got). Anytime you're doing login stuff over HTTP, it's never safe/secure to store anything in cookies.
Related
Passport by default allows the same user to login from multiple browsers and have unique sessions created. How can I configure it to destroy the first session when the user tries to create a second session?
Currently I'm using the 'Sessions' model to add the username to the record and upon subsequent login check by username if the sessions exists. But this increases traffic to the db. I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified. I'd be thankful for ideas around how to achieve tweak with express for this purpose or any other workaround/suggestion.
Much thanks!
I saw that at least 4 users upvote this question, so I decided to create passport-strategy for that. The new strategy called passport-one-session-per-user. It's open source strategy you can access here: https://github.com/AminaG/passport-one-session-per-user
How to use it? add it right after session. For example:
app.use(passport.session())
var passportOneSessionPerUser=require('passport-one-session-per-user')
passport.use(new passportOneSessionPerUser())
app.use(passport.authenticate('passport-one-session-per-user'))
Not need for settings, or configuration.
How it is works?
The strategy, created an array that contain serializaed user objects, and sessionID.
Every time user logged in, the strategy check if the user already logged in. If so, it's flag the other session. The next time the user in the other session make a request, the strategy see the flag, and log the user out.
I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified.
I believe the session model loggs the user in, and saves only that logged-in-ness in the session cookie. The server itself has no clue about who is logged in, but just checks this state in the (signed) session cookie provided by the browser.
You can write your own Passport.js strategy to handle it differently.
If I change another user's data, their session will hold their old data until they logout. In cases where I am, for example, changing their status to ban the user, this is not ideal.
Thus far, I have thought of two solutions:
Create a user-expiration value in the session, forcing an update from the database once that time has passed. Downside: not anywhere near instant, tons of unnecessary database calls, and seems awkward.
Use databases to manage sessions, somehow link the user's session to their user_id, and 'flag' the sessions for an update. Downside: forces me to use database session management, requires an update on all matching user sessions (which could be a lot, depending on how users use the website), seems awkward as well.
Is there a better way?
You can store the sessions in the database (and include the user_id) and you would query the users table on each page load, to see if the user exists/is active.
Let's say a user is banned in a website, but his session is still active. What's the best way of preventing him from performing an action that a banned user is not allowed to do?
The two plausible solutions I came up with are
making an additional checking previous to every "major" action,
like making a post in the forum, sending a private message, etc. to make sure
he is not banned (checking with the database)
destroying his session
Now, the latter solution could be done by setting an expiration for the cookie, but this would be bothersome for the rest of the users as they would have to log in again.
Other option would be setting a timeout in the session in which the scripts checks if he's banned with the database and then destroying his session if he is, but this seems like a bit too much.
What's the best way to deal with this?
If I understand what you mean by setting an expiration for the setting cookie, I would recommend against it. You want the control to be on the server side - don't trust your clients; they can easily prevent a cookie on their side from being destroyed.
Hopefully, whatever framework you're using has a way to delete the server-side data associated with a user's session, instead, invalidating the client's session id.
If your application is object oriented, you could do a check in your constructor, if the user is banned, and if he is, unset his session/call the log out function.
We have merchants logged in to a system, from which we want to link them to our Magento instance with some kind of admin token that will log them in directly without them having to manually login.
I see the rp_token field in the admin_user table but that appears to be related to a password reset, which probably isn't what we want.
Have done a bit of searching, found this thread which is related but is dealing with secret keys specifically (which will probably be my second challenge to resolve after resolving this one).
I'm guessing this isn't supported in core, but maybe there's a good extension out there to do it?
Or if not, what would be the best approach to implement? I'm guessing there is probably an event I could hook to look at a GET or POST param (which maybe could be a hash of the username and hashed password), then bypass the normal login() method which relies on username and plain text password.
That feels like it could be a little risky though? Any thoughts?
That feels like it could be a little risky though? Any thoughts?
This is extremely risky, but it can be done safely. I can speak on a similar issue I had in developing QuarkBar, an administration bar for Magento that is set to release this weekend.
So to show the bar, I need to verify the admin is logged in. Unfortunately that's hard to do on the frontend module, since there are two separate sessions. So to get around that I've created a quarkbar_session table. I use OpenSSL to store a secure crypt key once an admin is logged in, that I then check for on each request and match it to a cookie. If it matches, the admin is verified.
It's a little different from what you want of course, since I first set the key when the admin is logged in (it's an observer event). But it should get you started.
Source (NOT ready for production, use it for ideas): https://github.com/zschuessler/QuarkBar/tree/master/app/code/community/Zaclee/QuarkBar
Also, note that I'm storing the secure key so that I can access the admin backend. The solutions in your link say to disable it. You don't have to, check out QuarkBar for implementation.
Here's the issue at hand: I have developed an ASP.NET MVC3 application using Razor. I have also implemented a custom membership provider and overridden the ValidateUser() method. Within, I query my db and get a lot of user information in addition to the password auth.
At the moment, I am pushing this information, i.e. companyId, to static properties of a class. This works and I can display/use this information throughout my app. The problem arises when a user closes their browser tab. Upon re-opening the app, the user is authenticated via a cookie, so they don't need to re-login; however, those static variables are blown away.
So guys and girls, how would/do you conquer this issue? Should I append the extra info to the session cookie? Or perhaps a better solution?
Use the ProfileProvider in ASP.NET.
For application level variables, they are going to be subject to application pool recycles and similar "simulated" restarts related to users starting all over. These variables should be completely independent of user usage and should be able to be recreated easily. If you have variables that are user dependent or that can't be restored easily without some sort of outside intervention then you will definitely need a different method of storage.
If the data is user specific, storing it in the session cookie is probably the best idea. If the data is user-related but branches multiple users it should be stored in a database or a flat file somewhere. If the data has nothing to do with users specifically then it should just be in a database or configuration file.