I am using Asp.net MVC 3 in my project. I have a simple login page which takes username and password and after successful login, take me to the required page.
The problem is when I press back button from my browser and then press forward button again and again, it takes me again to the page without getting username and password from the user.
I don't know, may be it is the problem with sessions state. Because I didn't make any sessions and I don't how to make it.
Please anyone out there help me a bit to mitigate this problem.
Your session id is stored in a cookie, on successful authentication, the cookie gets stored on your machine, when you move forward in history, it doesn't get removed.
If you explicitly clear the cookie on each visit to the login page using:
Session.Abandon()
this will kill the authenticated session and create a new anonymous one, which shouldn't have access to the restricted page
Related
In a spring security application i am navigating to the login page and entering my credentials and getting logged in.Now again if i open a new tab in the same browser and navigate to the login url it shows me the login page.If I enter another users credentials and login my previous Jsession ID(ie: the one created in the previous tab) is getting overridden with the new jsession id.Upon refreshing the previous tab the session is overridden.
I want to implement that if a user is logged in already in the application, upon navigating to the url again in another tab on the same browser the homepage of the application should open.
Please advise as how I can accomplish that?
Since the server uses the cookie to map to the current session, you'd have to control how the browser sends cookies. Every time a request is sent to a website from a new tab, most browsers will send all the cookies it has for that domain. Since your server received the same session cookie, it will treat this request as being in the same session. There's no way it can tell the difference.
Therefore, as far as cookie-based web sessions go at least, you probably won't be able to force the creation of a new session upon opening a new tab.
In implementation of Login, I want to make sure if a user is already logged in one tab of the browser and opens the same web site in another tab, he gets redirected to homepage rather than the log in page. It's an ideal scenario as it happens in all the web site. I am achieving the same by storing logged in unique user token in local storage. Is it the best way to achieve it? Kindly guide! is it safe? If not how to go about it?
Just consider everything on the client as tainted or possibly manipulated.
So basically you should always check on the server side if the client has a valid session and only then deliver the homepage to it.
I would use a cookie set by the server side - just a random id bound to the actual client session on the server.
So the client could mess with that, but would have a hard time to guess another (also random) session id.
The cookie should be cleared by the server if the user logs out.
Then I would check on every call if he has a valid session id and if not directly send him to the login page by a redirect. Additionally you could then send him from the login page to the homepage whenever he is already logged in.
I'm maintaining a system built in ASP.
The login process is in SSL. Meaning, when the user clicks on "Login", his user name and password are sent securely to the server.
The login process produces a Session object, which is the ID of the now logged-in user.
After finishing the login process, the page redirects the browser to a non secure page. This page tries to access the ID Session object.
Until last week, this worked fine. Our system was running on IIS6.0, and the non-secure page could access this Secure ID Session object.
However, after switching over to IIS7.5, this inevitable security hole was closed(or so I assume). The non-secure page cannot access the Secure ID Session object anymore.
Access to the object is done simply like this:
string ID = Session(SESSION_USER_ID)
just to check things out, I tried access a non-secure Session object from the Secure login pages - this failed as well.
Is there any way to access a Secure Session object from a non-secure page?
BTW, I've probably mistaken with some of the terms here, but I think the scenario is more or less clear. Please tell me if this is not the case.
I've come across this problem before, I ended up getting around it by, when changing into or out of SSL, calling a function that would write the session variables to cookies, and then read back from the cookies into the SSL session variables.
A user has 2 ways of getting to this MVC3 website.
Through a log in screen.
Redirect from a different website.
I'm currently just showing a session time out page if the session timed out. However, the business now wants to redirect the user back to where he came from on session timeout.
How would I know where the user came from?
By the time I'm out of session, I don't even know who the user was. Although, that wouldn't make a difference, since the same user could come from either place.
Tricky. You could use a similar technique to what happens when you request a page that requires authentication. In that case, you are redirected to the login action, but the original request is added to the query string with http://localhost/Account/Login?returnUrl={your original request here} so that you are taken to your original requested page once you are authenticated.
In your case, you would have to save to the current session the incoming HTTP_REFERER on the login page, then add that as a '?returnUrl=' for every link to the logout page. Then you'll have to add code to the Logout controller method to handle the redirect.
Note that this technique won't work with deep linking to restricted auth pages (as described in the first paragraph), since that would require two redirects. The referrer would not be valid at that point.
After the username password login form is submitted (presumably with some kind of encryption through https) how does the server maintain the information that the user is logged in?
The user submits the login form and the server authenticates the user and returns a page. But when the user clicks on a link on that page how does the server know the request it is receiving is coming from someone who is authenticated and therefore the server knows its safe to send the html for that new page.
The act of logging on will usually result in the browser getting a session cookie passed back. It's this cookie that the server uses to identify which session (if any) belongs to the user.
If cookies are disabled on the clients browser, most web programming frameworks will cope by sticking a session ID onto the URL.
the username and some flag like is_logged are stored in the session.
on any page you should check those variables from the current session.
on logout you clean the session or destroy it, thus your protected page is in accessible.
good luck
Arman