I have a javascript client and an asp.net server. I am using simplemembership provider style authentification, the login/register and roles are working fine. The problem is, once the user logs in, I have to be able to check the future server controller hits and determine whether to permit or deny the user to use those controller functions. My first thought was using sessions, once the user logs in I would have the created session store his username (or id or whatever), and use that later to check whether his role has sufficient rights. The problem occurs when the log in function is hit, the session is created and the credentials are stored, but as soon as the function ends the session ends (which means I can't check his future controller hits). My question is, is there a way to makes this work this way (lets say somehow forcing the session to stay open until logout or timeout), or am I going about it completely wrong?
Thank you in advance, and I hope this isn't one of those "stupid" questions!
Related
I'm working on a C# MVC application where users submit applications to administrative users for review. Applications can be approved or denied by administrative users. My home page for administrators renders a list of submitted applications, and clicking on each application opens a new page where applications are processed.
My concern is simple: since the "Id" attribute for each application is a hidden html element on the admin "Process Application" form, it is possible that a user could modify the application ID and submit the form (in turn approving/denying the inappropriate application). I can get around this by using a Session object for "AppId" and verifying the AppId posted by the form is the same as the session AppId.
However (and this is the real problem), if I set Session["AppId"] = applicationId that session object can easily be overridden if the user was to let’s say attempt to process another application before submitting the first. Perhaps the admin user fancies their self a multi-tasker and opens two "Process Application" windows. Essentially, the first Session["AppId"] will be overridden by the second. This causes a problem on postback because now I can't validate anything based on Session.
While writing this, I realize I could add controls to prevent the user from processing more than one application at the same time. Is there an alternative approach though? Also worth noting, only admin users would have the ability to forge an application ID, which is unlikely because the Web-App is meant to help the admin users. Really I’m just looking for a best practice for these scenarios, as opposed to fearing someone will actually forge elements on my form.
Is my best approach actually storing an AppId in session, and preventing admins from processing more than one App at a time (so that the session object isn’t overridden)? It would seem so, but I’d love advice from the community.
PS: I realize this issue is similar to Secure way to stop users from forging forms. However, I think the biggest difference is I’m currently allowing users to process more than one application at a time, which prevents me from using a single session object for “AppId”.
I'd approach this from the "sanity & security" point of view. Users should only be able to change what they are supposed to change, data should [also] be validated on server side, and then you can disregard all forgery :-)
The best approach I’ve found is to check the AppId session object on page load. If it exists, then the user did not finish processing the original application (that scenario can be handled in various ways. I'll let you decide what is best, but you could probably redirect the user back to process the original application with an appropriate warning message explaining what happened). This is the only way I can think of to prevent the forgery of an AppId on the form using a single session object.
I'm working on a .net application that uses wsdl to connect to another service (the service is SpiraTest). I need to call authentication method in every request. The problem is that the service only provides a method to authenticate with a username and a plain-text password.
What would be a good way to save the username and plain password? I'm considering putting them in a session if I don't better options?
Users log in with the credentials to use the app and I use the same credentials to contact the remote service. User log on only once, but every time they navigate through pages that need data from remote service, I need to authenticate using the credentials that user gave when logging in.
Session consume more memory in server side and it is not good solution for your Task. What I suugest that Form authentication in asp.net. It create a cookie based on the credentials you have passed for authentication and it will be kept on browser until you log off from your App
http://www.codeproject.com/Articles/13872/Form-authentication-and-authorization-in-ASP-NET
I hope it may solve your problem
I'm not familiar with ASP.NET sessions, but I'm assuming they're similar to PHP sessions. In that case, the actual session data is kept in a file on the server. If you're just trying to keep your users from seeing this password, I think that keeping them in the session would be sufficient.
However, you haven't told us exactly how this username and password come to exist and are used. If you have just one username / password that your application uses to make requests to the web service, there is no point in keeping them in the session at all - simply store them in a global config.
I understand that when a user logs in to MVC webapp (when runtime executes FormsAuthentication.SignIn(..)), that user receiver a cookie and continues to work with the site with that cookie.
However the user can login again, from incognito window or another PC and get access to the site from both places simultaneously. I would like to prevent him from doing that.
I believe that the solution of this issue lies somewhere close, however nethier googling nor digging into MVC Forms Authentication classes provided me nothing I could work with.
So how do I forcibly sign off the last user login info (I believe it is a cookie stored inside a web server, I might be wrong) when that user successefully attempts to login in somewhere new place?
You need to implement
Application_AuthenticateRequest
in your global.asax file an validate that the user identity is still correct. e.g. you need to keep track of all session related to the user and which clients he used. You can then respond with a cookie reset in the mentioned method, if you want to sign out the user.
The only way you can do that, is by storing the user login in information in a table. So when the user tries to log in again, you can verify weather he is logged in some where else by quering the table. Once the user logs out, delete rows from the table.
Remember you would not be able to do anything with the help of cookies. Cookies will just contain form authentication ticket, which would be used by authentication module to verify whether the coming request is authenticated or not. And since the calls are stateless you can not decided anything just by looking at the cookie
I am looking to upgrade a project I have from ASP.NET Web Forms to MVC 4.
In the process of the upgrade I am trying to re-evaluate the way we handle authentication and login.
Currently, when a user attempts to log in, I (the front-end), make a call to the database to validate and then that comes back as yay or nay with an associated 'token'. I then have to pass that token to the next page on our site where it gets placed into a javascript object. That token is then passed with every ajax call and is updated after each with a new token. I personally manage that token within the client browser.
Now, in MVC 4 the default Internet Application comes with the needed logic to employ some form of local registration and login. But I don't understand how it works.
After a user 'registers' where does that get stored?
When a user is logged in and then changes pages, how does that user stay logged in?How does his credentials get passed?
It seems to me that the current way that we handle our login is grossly outdated and flawed. But at this time I do not understand how I could setup MVC to look at our current (external, its not within this project) database to authenticate users.
I have a book on MVC 4 but it doesn't seem to go into detail on how this works.
Any help would be appreciated.
Thanks!
After a user 'registers' where does that get stored
If you used VS2012, ASP.NET MVC 4, it will store the user in LocalDB. That's the default out-of-the-box implementation that uses the new Simple Membership Provider.
When a user is logged in and then changes pages, how does that user
stay logged in?How does his credentials get passed?
The currently authenticated user is stored in a encrypted Forms Authentication cookie. Look at the LogOn POST action which emits this cookie.
I had a similar question, you can see my post here, but the solution I found and went with was from this article. It's very detailed with how the new SimpleMembership system works.
The biggest change is that you no longer need any of the aspnet_regsql stuff anymore. Once you register, the database schema gets created along with a row for the user. No SP's or Views required!
I have to design a CMS where a set of credentials can only be used once. So if a user has logged in from his computer, no-one can login with his credentials from another location until that user logs out.
Now using the asp.net membership provider out the box, the IsOnline method returns a boolean that reflects the timeout window vs. the last activity date. This is not a viable option for me, because if the user just closes the browser after logging in, IsOnline will still be true. But his session will be destroyed(assuming he's not using Remember Me) so if he tries to log in somewhere else it will say "Sorry you still logged in".
Are there any hard and fast options for doing this..?
I was thinking of forcing the users to be "Remembered" so when he logs in a boolean "IsReallyOnline" will be set to true and vice versa when he logs out.. Although this option has it's limitations, (people turn off cookies, not logging out and closing the browser then sum1 else comes and browser to the site and he's logged in etc....) it seems like the most viable for now?
Any suggestions?
Thanks in advance
You are really asking for something that is outside of the remit of the web. The HTTP protocol is by definition stateless, meaning that at any one time; a server never need know if a client still exists. The newer/older implementations of web server programming languages (e.g. php / asp.net mvc) for the most part shy away from storing any state about connected/active clients.
Some things to ask yourself include:
How long may a user be 'active' on a page without causing a postback? Javascript based pages may allow for a user to interactively be using a page for quite some time before any kind of postback happens.
Will the users be going through a proxy or caching server? Multiple requests from 'different' users may come from the same machine in this case.
Will your application be running on one machine only, or maybe a server farm? You'll need to ensure that load balancing (for example) doesn't punt different users onto different servers allowing multiple logins.
How about a user legitimately using two different browsers on the same machine? Is this to be allowed?
One might suggest your problem here stems from trying to use the wrong technology given your requirements? Maybe writing a client application which uses direct connection to your servers would be more 'secure'? (Yes I understand this is huge hassles but if your one user / one logon requirement is absolute maybe you could explore this avenue?)
Oh alright, a web solution
For a http centric solution you could try a javascript timer making a request to your server every X seconds to indicate that the session is still active. As long as the browser is open and the network connection valid you should be getting these 'pings'. The session is kept open by the cookie passed by the httprequest.
You'll be able to code the 'ping' page to store the user details into either the application object or some membership provider of your choice then interrogate this provider whenever a client attempts to log in.
This will require a relatively short time-out on a session or some other mechanism to ensure that a crashed browser doesn't lock your legitimate user out for too long.
Please note: This will fail horribly if the user doesn't have javascript turned on (Don't assume that they will have!)
Fast Option: Store IsOnline as a session.
Check if session is true, then allow. If not, don't allow.
If user closes browser, he will be logged outas its in a session.