I heard in an old stackoverflow podcast that they minimized the use of sessions, and that they basically only needed it when posting. How can that be? Don't they need to use some form of sessions on every page view if nothing more than to tell that I'm logged in? How else do they show your username instead of the "Log In" prompt at the top of the screen?
When this type of thing becomes important is when you're persisting your sessions in a database. Now each time you touch your session store, you touch your database. So it would be great if you could avoid it.
You could store all your state in a cookie, but if you care at all about security, then you'll probably want to control state on your server instead.
I don't know about the podcast you're referring to, but I'm not really sure they were saying what you thought they were saying...
Session data doesn't necessarily have to be written to DB everytime it's touched. You could easily have a cached (using memcached or something similar) intermediary. You could then write the session data to DB every X amount of requests/minutes/writes/whatever.
Related
So for the login, since it doesn't really make anything new in the database but rather just returns if we've logged in, and possibly some user data, should it be a command or query?
And as for the register, since it creates a new user, should it be a command then? What if i want to return the users data or a jwt?
Should i run my commands and once the client receives a response run a query right after them?
As with most design related questions, I’d answer this one with ‘it depends’. I have seen both solutions implemented in different situations.
The main question you’d need to ask is whether you consider a user logging in as a state change of the system or not. Note that whether it changes state in de database isn’t relevant. The system is more than the database.
Log in as a command
For some systems, it’s important to know which users had been logged in and when, from where, etc. One example I had seen was a medical system that needed to record which doctor logged in when and where, and which medical records had been accessed. Also, logging in on one machine would stop tbe session on another. A reliable trace of these actions was essential to the application. As such, log in was implemented as a command which generated events that were stored in the Event Store. Projections kept the current logged in state for each user.
Log in as a query
Most systems I have seen, however, simple beed to know whether any given credentials can ve mapped to a user account. If that is the case, a token is generated containing the ‘proof’ of authentication. The system itself doesn’t really care who is logged in. It’s just that each request needs to be validated by checking the ‘proof’. In this case, logging in is a query.
I use a user object (attribute email, display name, permissions…) on several areas.
Is it possible to load the user details after the login and save it for the complete live time?
Or I need to reload the user information from Azure database by each load a new page?
Regards
Stefan
Your question is hard to understand, but if you're asking if you need to query the user with each request, the answer is yes. HTTP is a stateless protocol. Each request that is made is as if nothing happened before or since. In other words, the fact that you queried something from your database on a previous request has no bearing whatsoever on the current request.
You can use sessions to fake state, by persisting a serialized representation of the object in the session store. However, the session store will be a database, itself, if you're doing it right, so it still would involve a query. The only benefit would be that the query would be simplistic. In other words, there's some value of persisting to the session or some other form of cache if your original query was extremely complex and/or time-consuming to complete. However, querying a row by id is about as simplistic as a query can get, so that's not the situation here.
Long and short, if you need the user again, just query it again.
In my application I want to prompt a user about a new feature with some kind of a dialog the first time they visit the screen. And on a subsequent visit this dialog is not shown.
The obvious solution is to use a cookie or save this in the database.
But I'm concerned that:
- over time all the checks in the code will result in messy code
- with the database solution - it can bring performance issues.
And also if the user clears his cookies (for example) I don't want them to see every new feature update for the past two years (one screen can be have multiple new features over time).
Is there a stupid/simple way to handle this? How does twitter and facebook do this when they promote their new features?
My environment is MSSQL, ASP MVC if does matter.
Use both - cookies as a caching technique - first check the cookie. If it doesn't contain the flag - then ask the DB.
Also, you can initialize that cookie at login. One DB call per user session.
Personally, I'd use a database flag against the user record.
Like you say, cookies can be destroyed and lead to annoying duplicate reminders.
I don't think you need to worry about "messy code" if you're doing it right.
Since you have user login, I assume you also have some type of server-side session. You could store user preferences in the database, and cache them in the session upon login, avoiding going to the database for every request. As long as you trust your session for authentication purposes, you certainly can trust it for user preferences.
We store it in XML. Then you can use serialization to quickly save/load the settings. We store the XML in SQL (MS SQL have features that support XML)
Well the checks in the code are independant from the place you store the datas, it is a different problem.
As of your question I'ld say to use the database, for speed + ease reasons.
how do I prevent my users for more than one simultaneous login per account. I am using Vb.Net SQL.
Just coming from a 'web programmers' point of view, there is one really simple way:
You have to use some sort of central session system, where a Cookie on the user's browser has a hash, or some unique key that is also stored in the database. One each page request, or at set intervals, you check if that hash exists in the database.
Then, whenever you have a user log in, you delete any hashes that are tied to that user in the database, and then you create a new one for the user logging in.
What happens is if a user logs in, and you delete existing hashes from the database, then the other user will be logged out when you go to check for their hash in the database.
Not VB-specific, but: when the user logs in, keep track of the fact they are logged in. You can keep this in a cookie (watching out for the fact that a cookie can be tampered with.) You can keep track of it in a session variable. Or you could keep a boolean field in the database, "is_logged_in".
Then, when the user attempts to log in, you can check to see if they've already done so. If they're already logged in, the script might just return them to the home page (provided they used valid credentials. Otherwise a rogue user could type a username but leave the password blank, and depending on the behavior of your program, could see if a user was logged on at that specific time.)
Also, it is common that when someone is logged in, the webpage itself replaces the "Login" link with some text that says "Welcome, rascher!" and maybe links to their profile or preferences page.
Edit: Also remember to set is_logged_in (no matter how you track it) to "false" if they log out. It might also help to time this out - say, when the user closes the browser, or after "n hours" of inactivity (though that can be really annoying.) It will depend on how long people are generally logged into the system. Also note that someone might log in on their home computer, stay logged in, and then try to log in to the same place from work or their iphone. You might could look at ways of dealing with this (if the IP address is different than the current login, then log the other person out? Or something.)
I am currently building an internal web application used in a factory/warehouse type location. The users will be sharing a single PC between several people, so we need to have a fairly short session timeout to stop people wandering off and leaving the application logged in where someone else can come to the PC and do something under the previous user's username.
The problem with this is a session can timeout while a user is currently entering information into a form, especially if they take a long time.
How would you deal with this in a user friendly manner?
Keep the server informed about the fact that the user is actively entering information.
For instance send a message to the server if the user presses the TAB key or clicks with a mouse on a field.
The final solution is up to you.
Use AJAX to regularly stash the contents of the partially filled-out form so they have not lost their work if they get booted by the system. Heck, once you're doing that, use AJAX to keep their session from timing out if they spend the time typing.
The best advice would probably be to ask the users to close the browser window once they're done. With the use of session-cookies, the session will automatically end when the browser is closed or otherwise on a 30 minute timeout (can be changed afaik).
Since there by default is no interaction between the browser and the server once a page is loaded, you would have to have a javascript contact the server in the background on forms-pages to refresh the session, but it seems a bit too much trouble for such a minor problem.
If the session timeout is so short that the user doesn't have the time to fill in a form, I would put an AJAX script that makes a http request to the server, every few minutes, to keep the session alive. I would do that only on pages that the user has to fill in something or has already started filling something.
Another solution would be to use a session timeout reminder script that popups a dialog to remind the user that the session is about to time out. The popup should display a "Logout" and a "Continue using application" that makes a ajax request to update the session time out.
Maybe that a keep-alive javascript process could be helpfull in this case. If the script capture some key triggers, it send a "I'm still typing" message to the server to keep the session alive.
have you considered breaking the form into smaller chunks?
Monitor the timeout and post a pop-up to notify the user that their current session will expire and present "OK" or "Cancel" buttons. OK to keep the session going (i.e. reset the counter to another 5 minutes or 10 minutes - whatever you need) -or- Cancel to allow the session to continue to countdown to zero and thus, ending.
That's one of lots of ways to handle it.
Using a JavaScript "thread" to keep the session open is, to me, a bad idea.
It's against the idea of session timeout which exists to free some resources if there's no user in front of the application.
I think you should adjust the session timeout with the more accurate time, in order to fill the form in an "typical normal use".
You may also be proactive by :
having a JavaScript alert displaying a non-intrusive warning (not a popup) to the user before the timeout expire, which say that the session will expire soon (and give an link to send an ajax request to reset the timeout and remove that warning - that will avoid the user to lost the form he is currently typing),
and also have a second JavaScript "thread", which, if the session has expired, redirect to the login page with a message saying that the session has now expired.
It think that's the best because it avoid the user to fill a complicated form for nothing, and handle the case when the user has gone away.
As an alternative for the technical solutions, you could make your application in such a way that everytime a particular job is done, for example filling in a form, you ask the user if he wants to continue doing another job or if he's done. Yould could have a startscreen with menu options and if the user chooses an option he first has to enter his credentials.
Or put a password field on the form. Depends on how many forms they have to fill in a session.
When the user posts the form and their session has timed out, you should make sure you save the form values somewhere and then ask the user to login again. Once they have re-authenticated you they can then re-submit the form (as none of their data will have been lost).
I had developed something requiring very long session. The user logged in on a page when he sit on the machine and after doing his work, logged out. Now he may use system for few minutes or for hours. To keep session alive till he logged out, I used timer with javascript, it went to server and updated an anthem label with current time on server.