Regarding a clock in/out site. When user A logs in it shows his check in/outs. then user B logs in. When A refreshes the page, he gets B's Check in/outs.
I am probably doing this wrong because iam storing the username in a public variable when ever the user logs in server side, c#, too check for a lot of other permissions on the site, through different pages.
if (publiclasses.isValid == true)
{
publiclasses.unilogin = UserNametextbox.Text.ToString();
publiclasses.Checkifmissinglogout();
Response.Redirect("checkin.aspx");
}
How do i save the user in a different way that always keeps it "unique" and not just overrides the old one stored?
Using a public variable will be shared across all user sessions and it introduces concurrency issues, all of this assuming it is static.
To separate it, you have to use sessions.
ex:
Session["unilogin"] = UserNametextbox.Text.ToString();
You have to make sure you use the session variable in any piece of code you reference the current public variable
You need to implement some kind if identity for your users. There are loads of ways to do this, but it depends on the exact ASP.NET variant which will be best for you. Most web applications use cookies for this.
Basically when user A signs in they get a cookie that says they are A. Every subsequent request they make will have that cookie attached and you can get which user they are from it.
At its very simplest this is very easy:
// In sign in POST back
Response.Cookies.Append("user", username);
// In further pages:
string username = Request.Cookies["user"];
However, this will make it very easy for B to pretend to be A - it isn't secure. The built in .NET methods will create an encrypted cookie that's much more secure.
Related
I'm working a web application, which is MVC 5 + Angular JS hybrid. There is no authentication in the web app and an anonymous user can come and ask for price for certain services. To get the price the user needs to answer some questions spread across few pages. Here is the flow of app.
User clicks button to get price
A unique URI the request is generated and user is redirect to the questions page
User answers questions and user submits the answers. The questions are spread across multiple pages navigated through angular routing. The answers are saved back to server on page navigation.
Once, the user submits the answers, the system (server) generate the price and display it to user.
Currently, if the user has bookmarked the URI, he can come back after days and continue from where he left. I want to prevent this behaviour.
What are the different options do I have in MVC? I can think of following:
Using HttpCookie with expiration time
Save the last access time in DB and validate if the user has come within a stipulated time frame?
I would like to avoid HttpSession. I'm inclined towards using HttpCookie since it looks to be the simplest option.
If we go with HttpCookie option, are there any side effect that I need to keep in mind?
Are there any other alternative within MVC I can look for?
If You want to expire some link without storage involved and your service need to be scaled I think You just need to add expiration date in your link and sign it.
I believe you can create your URL in a way like this
Pseudocode:
var info = [Payload any info you need to store(questionnaire id or so)] + [expirationDate]
var sign = HMAC256(info + [SERVER_SECRET])
var clientLinkParameter = info + sign
var clientLink = [baseURL] + [delimiter] + Base64(clientLinkParameter)
*HMAC256 - it's just example you can create signature using any algorithm you want
Now you can just check your link for expiration by parsing serialized data in the part before delimiter. You can also check that date was not modified by checking:
HMAC256([partBeforeDelimiter] + [SERVER_SECRET]) and [partAfterDelimiter] for equality. If they match this is the link your server sent (as only your servers know what the [SERVER_SECRET] is) otherwise it was modified by the client.
Now you can store any non secret data in user link allow user to share this link and other great things that you can do with a link without worrying that someone modify our link. Client can deserialize first part as well if its widely known serialization algorithm like JSON.
I think this flow will bring better user experience in case of suddenly closed browser (that will clean cookies in your case) and also sharing link with someone (if you need)
Hope this will help.
I finally, went with session-cookie. I hashed the unique id and saved it in the cookie with salt. I feel this is a reasonable approach for following reasons:
The anonymous user session is going to be short lived. Once, he closes the browser the cookie gets removed.
If the user bookmarks the URI, I look for session-cookie in the Http Request. If the session cookie is not found, I redirect the user to the challenge page.
I have gone for MD5 algorithm for hashing. I understand it is collision prone, but is faster than SHA. Since I do not store sensitive information like password in the cookie, I guess it should be fine.
I'd rather generate a token for a unique user session and store it on the server along with CreatedDate. So URL will have a token query string parameter that will be validated against the date.
It's more secure than relying on cookies
Allows for adding analytics to your site, where you start storing q/a combinations along with generated prices for a given user session. Start collecting data early. :)
I've got an application that's using the MVC4 Simple Membership provider. I've added some code to the Login method that sets up some session information I need to deal with some security things.
If I close the browser and come back to it, MVC still shows me logged in in the top left corner and the User.Username properties are still filled out, but the extra stuff I put in there, obviously, isn't.
When or where does this "authentication" take place? I tried checking the request and user objects in the Application_Start in Global.asax, but they're still null when that runs.
Is there somewhere else in that authentication pipeline that I can override or call my method to extract the things I need that would be more appropriate?
Thanks!
"Remember me" functionality has nothing to do with Simple Membership, or any membership. And no actual "login" occurs when using it. It's a persistent cookie that is placed on the users system, and that cookie is read when a page is loaded. If it contains the correctly encrypted data, then the user is considered authenticated without having to go through Membership validation again.
What you need to do depends on how you are doing it. If you're storing data in the session, this is bad regardless, because the session can be reset at any time, and session is not connected to authentication. What you need to do, is check to see if the data you need is in the session, and if not, rebuild it. This way it works when you come back later, or if your session is reset.
Session probably shouldn't be used anyways, because it doesn't scale well. A better choice would be to hook into the OnAuthorization method of the Controller class and do what you need there, that way it's done on every page request regardless of what the session may or may not be.
Another option is to create a custom AuthorizationFilter.
I have an ASP.NET application where most of the pages are accessible to all authenticated users via a single sign on module that sets the username into the Session array variable. Now I have one folder A containing one page B.aspx and a list of usernames who are allowed to access this page B.aspx.
My question: how do I elegantly authorize only these users for this one page, or better, for this one folder. Can it be done with the location tag in a Web.config file inside folder A ? If so, how do I connect that config with custom code to check whether the username stored in the session variable is one of the authorized for that folder or page ? Can I use a custom membershipprovider ?
Thanks in advance !
First, you scrap the kludged security methodology, as user name in a session cookie is not a good way to handle this. Okay, maybe a bit too overboard, as low security may be fine for you. If so, you can write a custom handler for the page that examines user name and compares to an updateable list.
NEW: With Session object, you are a bit more security, as the session token is sent over and the name is kept in session, but the Membership bits (below) handle translation of a particular session to a user without rewriting with your custom "this user is using this session" methodology. Yeah, ultimately you can argue Microsoft does something very similar to your software, but you leave the maintenance to them.
Going back to my original direction, there is the concept of roles and membership built into ASP.NET. If you use these bits, you can security trim the page (or even better folder so you can additional pages) to certain users (not as good) or roles (better) by setting up a new web.config with the security constraints.
The cool thing about the built in stuff is you can declaratively set up security and have the pipeline determine whether a user is valid or not without any heavy lifting on your part.
There is plenty of information on Membership and Roles on the various ASP.NET oriented sites.
that can be achieved specifying the user's name that can access the directory separate by commas.
As your username is not defined in web.config rather defined in some session variable you have to create a Form Authentication Ticket for this e.g.
FormsAuthenticationSupport formsAuthenticationSupport = new FormsAuthenticationSupport();
formsAuthenticationSupport.SignIn(UsernameInSession, RoleName, true);
Now you can set authentication rules and location tag in web.config for UsernameInSession.
How can I remember a user that is logged in without having a security issue? Currently, I am storing the id and a guid into two different cookies and compare them when there is no session alive. If it match then I re-create the session. Btw, both id and guid are nore encrypted.
Is this method safe enough, or should I follow a rather distinct way?
Since cookies can be easily stolen by use of XSS, does not matter if you place information in just one cookie or two, because a theft will take them all.
I have solved with a more complex procedure: I place one encrypted cookie divided in 2 parts (but 2 cookies will work as well), one fixed and the other variable each session. Both are saved also on server side to check: they are only session identifiers, no sensible information contained in the cookie, the correspondence with the user id is saved on the server.
If a fake user enters the account with a stolen cookie, the variable part (or cookie) will change, so when real user connects again he will not be able to enter and you will have the proof that an unauthorized access occurred: then you can delete the permanent session on server side (defined by the fixed part or cookie) in order to avoid any further access by the theft. The real user will re-login and create a new permanent session with a new cookie. You can also warn him that you saw a security flaw, suggesting him to reset password (operation that should never be accessible directly from cookie) or to use another browser for unsafe navigation.
If you save additional user information (user-agent, IP by location) you can check cookie validity also on them in order to avoid even the first entrance of the fake user.
I would recommend you using forms authentication for tracking logged in users in an ASP.NET application.
I was reading on session state, application state, cookies, profiles.. and i wondered way would i adapt to my site.
I am building a forum, and i need to check whether the user is logged in or not. If he is not logged in, he wont have the choices a logged user has (e.g. pressing the reply/start thread/submit messages buttons). Basically, i thought to plant a cookie onto the users pc..but some browsers dont allow cookies, then i thought i would follow with a session state for users who dont allow cookies. I looked at the modes of the session configuration that session state has got, and there was one that i liked.. it was mode="sqlServer", but then i read that it has a disadvantage of being slow, and that i need to install a few more components to make it work.. in other words it looks cumbersome. I also looked at profile option, and i think it is a solution.. as soon as the user logs in, i can set his name. Something along those lines:
protected void updateProfileButton_Click(object sender, EventArgs e)
{
Profile.Name = nameTextBox.Text;
Profile.Age = Int16.Parse(ageTextBox.Text);
}
Whats the best option that i have got,? i am thinking of using cookies in a combination with profiling!!
If you just need to have a mechanism to allow a user to access additional functionality when they are logged in then have a look at ASP.NET Forms Authentication:
ASP.NET Forms Authentication Overview
Update:
In answer to the two questions in the comment below:
should i set this user identity to the
cookie? User.Identity.Name;
No, once you've authenticated the user ASP.NET's Forms Authentication provider configures the cookie for you.
will it add an automatic password to
the web.config?
No it won't, you need to write your own mechanism to store a user's details which would typically be captured from a user registration page (e.g. username, password, name, age, etc) For example you can use a SQL or Access database or you could use the ASP.NET Membership provider:
Introduction to Membership