I have a <asp:Wizard> that is only applicable for a logged-out user. If the user is currently logged in, he/she is redirected to another page. On one of the wizard steps, as part of the wizard, I ask for credentials via the <asp:Login> control and log in the user. This presents a problem.
According to MSDN: "When a user uses the Login control to log in to a Web site, all data in the view state and all post data is lost. Do not perform actions in the LoggedIn event that rely on the view state."
Because of this, my Wizard control forgets the step it's on after the login process. MSDN recommends: "If you embed the Login control in a WizardStep object, explicitly set the ActiveStepIndex property in a Page_Load event handler if the user is authenticated. The Wizard control does not automatically advance to the next WizardStep object in this scenario."
However, because all view state is lost, the redirect for logged-in users kicks in, sending the user away from the page. What's the best way to determine, at page load, which of the states the user is in?
Already logged in some time ago; needs to be redirected.
Was just logged in from inside the wizard; needs to reach the next wizard step.
Thanks for any ideas.
You can set a Session variable when the user logs in: Session("LoggedIn") = Now
When checking to redirect the user, check if LoggedIn was at least 3 minutes ago and then redirect.
Because you set this Session variable after logging in it will be available (or maybe null if not logged in).
You might want to create a custom Login control, inheriting from Login, that sets this Session variable whenever a user logs in:
Public Class MyLogin : Inherits Login
Private Sub MyLogin_LoggedIn() Handles Me.LoggedIn
HttpContext.Current.Session("LoggedIn") = Now
End Sub
End Class
"A strange game. The only winning move is not to play." Reference to War Games
Instead of playing the redirect-preventing game, a different solution is possible. Since I control all links to the page in question, when the a user is logged in, I can change the destination (href) of those links to the post-redirect page. This bypasses the need to "play" on the page itself, and allows the page, if hit by a logged-in user, to always jump to appropriate next wizard step.
Related
The goal:
I am trying to get the user to log off if they leave this area.
Area name: employer
if the user goes to the home page or anywhere else on the web and tries to log in or hits the back button I want the system to end the users session.
for example:
www.example.com/employer/dashboard - is protected and the user has to be logged in to access this area.
if the user goes to www.google.com and try to go back to www.example.com/employer/dashboard their session ends and they are redirected to the login page.
Some Questions:
Would it be a good idea to make an extend to the AuthorizeAttribute?
How would I log the user off?
How can I detect if the user leaves the area and comes back.
Should I make some sort of base controller that all of the other controllers inherit in the area so the area is protected?
Should the solution be server side?
any advice would help
For such purposes ASP.NET MVC authorization filters are used, which runs before any other filter.
the idea is to check if Path matches with Safe path then load area, otherwise don't authenticate and redirect to login. The tricky part is to control flow and not be trapped in page loop.
Check out this:
http://www.dotnetcurry.com/showarticle.aspx?ID=957
I will suggest to use window.onunload event and logout your user when this event occurs.
I'm using Forms authentication. I have a small problem after the user logs out. If he hits the back button after he logs out, he's sent to the page he was on when he was logged in.
What is the best way to prevent that? I've looked around but it doesn't seem that there's one definitive approach. Ideally, I'm thinking I'd like to have a function on the master page or even in an httpmodule that checks to see if the user is logged in and if not, redirect him to the login. Is that the best way to do it?
Thanks.
As long as you do Session.Abandon() and FormsAuthentication.SignOut() on your Logout page it doesn't matter whether the user can go back to the previous page he was in, the moment he clicks on anything will be redirected to the Login page.
Example:
Page_Load login/logout page:
if (!IsPostBack)
{
FormsAuthentication.SignOut();
Session.Abandon();
}
You may turn of the cache ability of restricted pages by adding following statement in page_load event.
Response.Cache.SetCacheability(HttpCacheability.NoCache)
Since the Back button in the browser is not controllable by ASP.NET (at least not in a way to disable it), I suggest that you do it like you suggested:
On every page, check to see whether the user is logged in, if not, redirect him to the login page, optionally with a goto parameter to redirect him back to the page he wants to navigate to after successfully being logged in.
I do it this way, too for most of our applications.
HttpContext.User has the IsAuthenticated property for you to check in every page. If you really want to use your custom session variable make sure you remove it or do Session.Abandon at logout and check for it in All pages anyway.
Is it OK to call FormsAuthentication.RedirectFromLoginPage many times?
On login page we test if user is already logged in, and if it is we just redirect him to default page with FormsAuthentication.RedirectFromLoginPage...
Question is if user sets a script that loads login page 10'000 times, would calling the FormsAuthentication.RedirectFromLoginPage that many times make problems?
Thanks
On login page we test if user is
already logged in, and if it is we
just redirect him to default page with
FormsAuthentication.RedirectFromLoginPage...
The times when user goes to login page when already logged-in is
(i) either they go to that page manaually(i.e. they enter the url to your login page)
(ii) or is sent their by some manual redirect in your code or
(iii)if he/she is unauthorized to view some resource and redirect by asp.net authorization module.
Depending how user reaches the login page you might want to take appropriate action. In any above cases I would not use FormsAuthentication.RedirectFromLoginPage. The only time I would use it on login page is when user clicks login button and credentials are valid.
FormsAuthentication.RedirectFromLoginPage will create a new authentication ticket everytime it is called. I would just do hard redirect for the scenarion you have described:
if(Request.IsAuthenticated){
Response.Redirect(FormsAuthentication.DefaultUrl);
}
You should consider the 3 points I mentioned above before using the code.
I am trying to manually implement a login system in ASP.NET 3.5. Basically, on load, I would like the site to check and see if user object is active, if not, than I want the login page to appear.
After user has logged in successfully, I would like the user to be able to access the same page he has requested originally.
for example:
user request to: MyPage.aspx - not logged in
login page appears instead of MyPage.aspx
user logs in successfully
MyPage.aspx appears instead of Default.aspx for example
Peering at the System.Net namespace, I see that there is an "HttpWebRequest Class" which has a "HttpWebRequest.AllowAutoRedirect Property" but am unsure how that would get me back from the login page.
NOTE: I know there are automatic authentication systems setup in ASP.NET, but I would like to have manual control over the database.
-- Tomek
What you could do, if you don't want to actually use the built in Forms Authentcation is:
Check if the user is authenticated on each page you want to hide from anonymous users. If they are not authenticated, redirect them to your login page with the URL in the query string.
if(!HttpContext.Current.User.Identity.IsAuthenticated) {
Response.Redirect(~/login.aspx?redirect=this_page.aspx");
}
Then on your login page, after a user logs in. Check the query string to see if there is a redirect parameter.
if(!String.IsNullorEmpty(Request.QueryString["redirect"]) {
string url = ResolveClientURL(redirect);
Response.Redirect(url);
}
Of course this is all built into .NET using Authentication, where you can deny anonymous access to certain directories, and when you do that, .NET will redirect to your login page (which is set in the web.config) and will include a "ReturnURL=blahblah" on your login page.
Just an FYI.
Just save the originally requested url in Session or a hidden field on the login page
After successful login, use Server.Transfer or Response.Redirect to jump to that page.
It looks like another method is described here. It seems that you can use the following object to return from the login page:
FormsAuthentication.RedirectFromLoginPage
Yet, according to the article, the better method is to use what JackM described, but with an overload:
Response.Redirect("~/default.aspx", false);
In doing so, you prevent the Session from ending when the page is redirected.
i am writing a login page in asp.net c# not using login control.
i can create account and log in without problems as a user.
the pages that require login has a separate master page.
and i want to check if the user is logged in in masterpage page_preinit function
but the problem is that child page event functions are called before masterpage's so i could experience a problem like session expire in child page before i get to check it in master page. is there anyway around this?
ok found the event im looking for. second one on the list
http://msdn.microsoft.com/en-us/library/dct97kc3.aspx
Are you using FormsAuthentication? You shouldn't need to worry about this. Authentication happens in the IIS pipeline before the Request is handed off to your Page object, and if the user's authentication fails, it will never get there, being redirected to the login page instead.
None of your PreInit code should be called by an unauthenticated user if the page is protected by FormsAuthentication.
This is one of many reasons why rolling-your-own authentication is a risky approach. There are lots of corner cases.
Since you're storing the user ID in the Session object, then once the session expires, you can't access it any more; it doesn't matter if it's from the child page or the Master page.
Instead of using Session, it would be better to use cookies. You could have a long life on the cookie itself, with the login expiration time encoded in the value of the cookie or kept in the database, keyed by the value of the cookie. That way, the session could expire, but you would still be able to refresh it or take some other action, rather than just reporting an error.