I want browser to remember the login until the browser is closed. So, if the user opens a new tab, he/she still remains logged in. I tried with the following two options stated in the doc:
https://www.firebase.com/docs/web/guide/login/password.html#section-logging-in
default - It remembers the user even when the browser is closed and reopened.
sessionOnly - It remembers for the current tab only. If the user open the app in a new tab, they are no longer logged in for that tab.
So, you can see we need another intermediary solution where user will still be logged in for the new tabs and that session should be alive until user exit the browser completely. This is the existing behavior that all websites follow for non-remembered login. And for remembered login, they use the default option.
That means, firebase is seriously in need of that intermediary option. My questions are:
Is Firebase going to have that intermediary remember option?
Until this options is implemented, is there a secure workaround?
Thanks.
Related
I'm currently planning my web application. I was thinking using Session to store user profile (user name, current database, permissions, etc...). Common scenario is where user opens several tabs for different pages.
Now, I need to have an option for user to change the database. Basically needs to choose the database from list, enter a log in information and it's done. Not sure how to handle this. It seems that browser tab where user initiated the change should somehow tell server that he needs a new session here or server has to inform browser that new session is generated?
Basically if user has 4 tabs open and initiates a database change on one tab then he should end up with two sessions? Is this correct or is there a better way to handle this?
As far as I am getting your problem, one thing can be done that whenever the user selects a new database and enters the log-in information then on selecting the new database, you need to clear out the old session details for the database and on entering the new session for login information, override the login details.
Also, store the old information into another session and whenever a conflict occurs you can navigate to the error page saying that "Login information and databse have been changed" or any custom message.
Only work around needs to be thought of for this scenario as in same browser the session value will be same throughout.
I have built an ASP.Net MVC site using Forms Authentication for a client.
Recently, they have requested that an authenticated user be restricted to a single browser session. That is, if the user raises a new browser instance, or opens a new tab on the original browser window, that he/she be logged out of the original. They insist on the added security.
Does anyone know how I might approach this? Thanks in advance.
Personally, I would push back and ask exactly what security this is bringing. Maintaining state like this counter to web architecture and is only going to bring you and your users grief.
Here is what I would do if presented with this problem:
Store the username of the user in your database (i.e. LoggedOn table).
When a user logs on, check to see if their username is already present in the LoggedOn table.
If the user isn't already logged on, insert a row into the table with the username and the current time; otherwise present the user with a message informing them that they can only log into the system from one device at a time.
Include logic to expire and delete the rows in the table if a user's session expires or if the user logs out.
First a disclaimer: I'm no expert in web programming.
Perhaps you might try a system where every user interaction requires the submission of a random value that's been generated for that page (much like what's used for CSRF protection.) That key could be kept under the user's session information on the server, and if a page is ever requested without the correct key as a URL parameter, the session is invalidated. The URL from one browser won't work in another, either, since once a URL is gone to, the user's session key has changed. The only way for a user to transfer a session between tabs would be to copy the URL of an unclicked link and paste it in a new tab's address bar. Switching browsers would be even more complex assuming that ASP.Net uses a session cookie: the user would have to transfer the cookie from one browser to another. Going back would also fail, as all the links on the previous page, and the URL for the page, would carry an incorrect session key.
Also, for reference, I believe the US Gov't TreasuryDirect site works in the way you've described, though I've never looked at how they manage it.
Thanks, people for the suggestions. Each had strong merits, however I had to take a hybrid approach. I found an incredibly simple suggestion from this post.
I implemented table of active users as Karl suggested as well. This will give the client the ability of deactivating the user on demand.
Thanks again.
Think of it as one active view at a time instead of one browser or tab. Or convince the customer to view it this way.
You can always issue a unique cookie for the browser session (ASP.NET Session) and allow communication to the latest cookie issued effectively making only one session active at a time, and therefore rendering other open sessions (browsers, tabs, etc) useless with the app by disallowing them communication any longer or serving up an error page for them. To do so you have to recognize who the user is and authenticate them against your app. This is half the puzzle and will force the user down to use your app in only a single browser at a time on their machine.
The other part of the problem is to pare down the windows and tabs that are part of the same browsing session of that browser, to allow only one view to be active at a time. To do so you can issue a unique sequential ID to the viewstate of each page for postback to the server to uniquely identify that page apart from other pages sharing the same session state (whether that page be in a browser tab, a frame or new window, etc). Or a code of your choice that's traceable. You then know which page is posting back within the session and can disallow others or deactivate previous ones by, again, shutdown down communication in some manner or serving up an error page, etc.
A new browser instance or a new tab may or may not be part of the same browsing session depending on how the browser is configured. I believe, for example, IE provides a setting that allows the behaviour to be set of whether a tab opens in a new process or session or shares the session. You won't necessarily get expected consistency across browsers to rely on for this feature, therefore you need to take programming steps to reign it in, like those described above.
You can additional steps like disallowing the user to be connected from a different IP# at the same time.
I have an application that requires a user to login. Upon login, a key is stored in the database for that login session.
I am having an issue when the user does Ctrl+K because it opens a duplicate window, which is now sharing the key stored to the database. I redirect them to the login page when they open a duplicate, but they are still allowed to click 'back' and they now have two windows with the same key - this causes MANY problems in my application...
How can I stop the user from going back - or how I can force login again (which creates a new key and both windows would then be valid) on any new window?
Thanks
How are you detecting that they are opening a new window? When you redirect them, can't you simply set a flag in your database that indicates that their current session key is not longer valid? This way, they are really kicked out - and not simply redirected to a login page.
okay - found a different way to handle this using window.name.
Thanks anyway all.
I'm using sessions for my login page that will hold the userId in a session. If two different users are logged using the same system and same browser but with separate tabs of the browser, the session value of userid is getting reset to the user who logged in last. Why?
there would be only one sessionID saved (in cookie) for a domain by the browser, which would be returned to server on subsequent postbacks to identify the session..
if you open another tab and login as other person, then the latest sessionID will override the previous..
So its not possible to have different logins on a same browser..but to use a different browser(not another instance of same browser)
If you are tracking authenticated users with cookies there is no way to achieve this because cookies are shared between browser tabs. It's the same with most sites. Take for example Gmail: you sign-in with one account, then you open a new tab and you are automatically logged in with the same user because the cookies are shared.
In order to achieve what you are asking you basically will have to change the way you are tracking your authenticated users. You should no longer use cookies.
2 possibilities come to mind:
Use a hidden field on each page that will contain the session id
Append the session id to the query string of all requests
Its not possible since sessions are shared between tabs. They need to use different browsers or the last user session will delete the previous user session
Internet Explorer offers a "New Session" feature on its File menu. This will allow a second user to login to your site whilst another is already logged in. However this will launch a new window, its not possible to run a separate session in another tab.
Other browsers may offer a similar function.
So its a ASP.NET problem where two users using the same machine, same browser.
User 1 logs in the domain.
User 1 changes some data without saving it.
User 2 logs in the domain in a separate tab.
User 1 switches back to his tab and saves the data.
User 1 actually saved the data into User 2!!
This is caused by the following mechanism:
Different tabs in the same browser seems to share the same session id.
We are storing user auth in cookie and the cookie is shared between tabs (same domain)
Therefore, when User 1 request to save, it is recognized as User 2 since the cookie has been updated to User 2.
So I'm wondering if there's any other methods to prevent this from happening, other than:
1. Use cookieless session so the session is embedded in uri.
2. Always include a hidden field in page to indicate which user owns the page.
Regards,
You could add some fields in the database to track that the user is logged in, and grab their IP address, and restrict access that way.
IE8 has a "New Session" command in the file menu that opens a new window, but that's pretty much like using 2 different browsers.
Hiding the login form until the current user is logged out will raise awareness that another user is logged in but won't prevent the above scenario. If the logout process could refresh each page in the browser on the domain then it might work, although user1 would loose all modified data.
I used the trick of opening a new window with a specific name and always make sure that any page will open always use that window.