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.
Related
We can use MasterPage for integrating the layout of the header and footer for example.
But we can use it for Server Sides operations like checking Session for user login.
Is this method risky? What are the disadvantages if we are using this method?
There is no disadvantages in the Session using master pages. Otherwise it helps checking session values, as no need to check the values at every page. It can be checked only in master page and will effect on all the pages.
I don't think we should check session for user login manually in code. ASP.NET provides us with Forms Authentication which already does that for us. Authentication is another concern that should not be mixed with page logic (separation of concerns)
Master pages can be used to check whether session exists of a authenticated user of no else redirect the user to login screen.
On login screen try using ASP.NET login controls.
I have a user control that only displays customer information on each .aspx page in my application. That user controls contains public properties for customer information those are set from .aspx page (say page1.aspx) OnLoad event and displays information in that user control. Now from this page1.aspx, redirects to page2.aspx but couldn't able to display information in page2.aspx usercontrol (the values are lost after postback). I could maintain user control's properties state by using session in each proprty of control and can access in all the pages, but sessions would be expensive ways to do that. Please give me another better solution about this, so that i can maintain user controls properties value across postbacks.
Thanks in advance...
The information is not lost in PostBack as the Page2.aspx gets a seperate GET request after doing a redirection from Page1.aspx
There are below ways by which you can do state management
Session State
Application state
View State
Cookies
Query string
HTML Web storage
Session state is what seems to be the logical choice for your scenario, As application state would affect the data for all the users who are logged in. Viewstate will be lost once we do a Redirection. For cookies there would be problems with size limit and you need to clear the data stored in cookies. Also, you should be encrypting the data stored there. Query strings are easy to be tampered & is not reliable. HTML Web storage is available only in latest browsers and hence browser compatibility would be a problem.
One other possible answer - you could use CrossPagePostback. This allows Page2 to automatically detect data passed from Page1. You'd have to do this on the page's load event.
A redirect will always take you to another page, and this will always lose any state attached to the first page. The only way you can maintain state like this is by not using a web application!
It's never really a good idea to keep the user information in a session and as little as possible in a cookie. Neither are secure and as you can see have some state baggage that seldom justifies it's use.
I recommend going back to the drawing board and designing a solution that keeps the information in a database obviously on the server; even if the record is purged at the end of the transaction. Watch that table and you'll be surprised how many sessions are dropped and never reach the "official" end of the transaction.
I am wanting to know when is the earliest point I can load additional user specific data like permissions into a session object right after login. I am using the membership provider but the data to be loaded is from a custom table. Session start is too late and I have tried the master page.
I'm also wondering where to put that logic to load the additional data.
I know it would be right after the user is authenticated but where? Global, login page, master page, default page etc.
Any advice would be great.
The earliest is obviously right after the user is authenticated. In other words, you should do it immediately your database call to confirm user credentials is successful.
The exact point it's difficult to tell without seeing your code. You may have user authentication logic on your login page (not a good architecture but it's quite common to see this) or you may have the logic on a business layer or a data access layer. You didn't show a piece of code as to tell you where makes more sense for you to have it but it's definitely within the login page or a call to another class made from the login page.
It is definitely not MasterPage or Global.asax
I have a several site collections in the same web application and I need to handle events when user goes from one site collection to another. I need it for specific actions, like setting "lcid" cookie for changing default language of site and claims values to user properties mapping.
Currently I'm using custom HTTP module, which handles all PostAuthorize web application requests and checks current user and site collection, holds last visited site for each user in collection and fires a custom event for subscribers, when detects transition between site collections.
But I think this approach slows down performance of web application. And from logs I see that there are to many PostAuthorize requests even when user simply clicks a link to page in other site collection. Also, in similar cases sometimes there is a series of requests to "next" site collection, then to "previous", and then again to "next". Also there are some issues with SharePoint Designer (can't edit page) become when this module is active.
Could you give me a advice with better approaches for this task? Thanks in advance.
1 way is using a hidden control and cookie.
Keep a hidden control in all the masterpage of all the targeted sitecollections.
This control will check the current site collection url and save it in a cookie. Possibly in the same cookie where you are storing lcid.
From next load onwards it will try and match the url in the cookie and the current site collection url. If different call the code you want to execute and update the url in the cookie.
This will be much lighter on performance than an httpmodule.
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.