I am writing an MVC 5 Intranet site with Windows Authentication.
The site is a questionnaire with the first two pages being information and instructions, on the third page I request the user to sign a disclaimer, from then on the user can't access any other part of the questionnaire, if the disclaimer isn't signed. What I want to do is to persist the action of signing the disclaimer to the database so when the user returns I can check if he/she has signed on a previous visit in which case I omit this page. I can't quite figure out where do I persist this information to database and where do I load it, and also how do I persist this information on the session.
Any advice would be appreciated. I have seen the suggestion on this page http://weblogs.asp.net/rashid/archive/2009/04/01/asp-net-mvc-best-practices-part-1.aspx
(see number 7) but I need to save more than just one piece of information I need to save an userinfo object.
thanks in advance.
Personally I wouldnt do it on the database, probably better doing this on the client.
You should just be able to simply set a cookie with a flag, if true omit the page(s)/Redirect else do nothing.
I guess the next question is 'do you need to know if a specific user has read the disclaimer?', in which case then store in the database as well for future reference. Depends if this flag is useful going forward or just to control the mecahanism.
Hope that helps.
Related
I have a webpage which has a form which allows users to add comments to the page to give feedback.
https://express-chat-comment-ap.herokuapp.com/feedback
You'll notice a user can delete comments, not only their own comments, but all of them.
So my question is, how would you limit those privileges to only that current user?
There is a major piece to all of this which is the web page is being integrated to a website which has a user login/user account already.
Also do I have to do any research regarding what back end their using now? Or can I keep this all encapsulated with Express/Node?
What packages should I use?
Where do I start?
Thanks in advance for your help!
You're putting the horse before the cart. This isn't really a "Node/Express" question; you're not going to solve it at the Javascript level.
Instead, your main question is actually "How do I do 'security'?"
More specifically: "How do I 'authenticate' users?" "How do I grant access?" "How do I prevent access?" And so on...
SUGGESTIONS:
User Authentication with the MEAN Stack
MySQL Authentication using Passport
OAuth 2 Single Sign on Authentication with Passport
Node.js: Token based authentication
Heroku: Managing Organization Users and Application Access
You must have an authenticated and logged in userID for each user that your server authenticates and understands. Each comment must be saved with the userID of the creator and you must be able to retrieve that from your data store.
Then, your server can check who the user is that is attempting an operation (probably from a logged in cookie that accompanies the request), what the operation that is being attempted and decide if that operation is allowed by that user. For example, if the user logged in is "Bob" and they try to delete a comment from "Alice", then the server will refuse to carry out that operation.
And, your UI in the web page can not offer operations that are not allowed (though the server must always check anyway). So, if you have a delete button in the comment, you would only show that button on comments that belong to the current user.
Hello fellow developers
I have obviously under estimated a thing when developing my first complex web site, where user creation and login is required.
It appears that cookies can be edited and modified by the user logged in, by using some developer tools i.e. in Google Chrome. That, I never gave a thought.
So, here is my issue.
When the user is logged in, I store the user name in a cookie.
If username-cookie is not blank, and I can find a user file with that name, the user is logged in, per se. Otherwise, no user is logged in.
When the user logs out, I simply expires the cookie, which works fine.
Now, the problem is, that a user obviously can edit the content of a cookie, outside the web application, or with javascript.
What would be the correct approach here to ensure, that the username cookie is not compromised in any way, other by my web application?
Making them read-only is not possible, I assume. Encrypting the cookie and then decrypting might work, I guess. Then, the cookie would be nonsense to the user, and if modified, result in a logout, as no valid username can be found upon decrypting the edited cookie.
I have stalked Googles cookies, and it appears that there are a lot of xxID cookies, which contains garbage. Does that mean, that encrypting/decrypting is the only way to make it work? I also considered some kind of login-ticket, but that would require a table lookup every time a user interacts with my web page.
Can anyone give me a hint as to what would be the correct approach?
Thanks in advance
Best regards,
Karsten Heitmann
You should look up session management for the language you are using.
The traditional approach is that when a user logs on, your application generates a long, cryptographically random token called the "session id" and sets that into a cookie. It stores data like who is logged in on the server side identified by the random value, so when a logged on user comes back, the browser sends the cookie with the random session id and the application can look up session data on the server side. This way an attacker has no way to guess a valid session id for a logged on user, assuming the session id is cryptographically random and long enough (which more precisely means it has enough entropy). Logging out means deleting the session data on the server side, and also removing the cookie, but that is not the most important part - the session will be invalid anyway.
Note that you should not code this yourself. You did not mention the language and environment you are developing in, but session management is rather tricky business if you want to secure it, and it is already provided by most languages / frameworks.
Just for curiosity, the encryption approach you mention is by the way a valid one. Some frameworks actually do that, but you should not attempt to code that either, because it is very easy to get it wrong, lots of things need to be taken care of to make it secure enough. Unfortunately an answer here is not the right format to go into details I'm afraid.
Btw you mention looking at Google. They use their own single sign-on solution, it is very complex compared to simple session management, so it's probably not the best example for you to look at. Find simple websites, most of those work the traditional way.
I was reading the wiki for cookies and they said it is needed to retain stateful information such as item in cart etc. But why do you need to do it? Why don't just store the state in database table for example?
You can store the state in the db but you need to know who is the owner of that state, so you need to identify the client in between the requests.
Think of the cookies like a caller id for the browser. That is their main use. When you hit my web server the first time with your browser, I say, 'hey, let me set this caller id somewhere on your browser' so next time when you call, I'll just read it and then I know it's you again. Once I know it's you, then I can look in my db for more info, such as your cart items.
Also the caller id I set can't be read or modified by other websites, if they want to identify you they need to set their own.
Cookies are useful to preserve information on the client side.
For instance, in the example you give, with a cookie you could save the cart of someone who isn't logged in or registered yet.
Whereas if you were using a database to retrieve such data, you would need a reliable way to identify the current visitor, and you probably wouldn't have many options apart from asking for a login.
In general, you would want to put in cookies information that would make the life of your visitor easier, but that is not essential to preserve (cookies do expire, they can be emptied, and the visitor could use a different browser etc).
I'm sure there must be a simple answer for this but I can't figure it out -
I have a Silverlight 4 OOB application that requires a login screen/security. The View shows a LoginView (Username/pw) which then passes the details to a WCF service and checks it against a database. It will return a result to the client to say if their details were valid or not. This part works fine.
Where I need some guidance is the best way of storing the fact that the user is logged on/authenticated for the current Silverlight session.
It's OOB so we can't use any web cookies/session stuff as far as I know. I assume we have to store some sort of Identity in the thread but I need some pointers please.
The other caveat is that I would like to secure all other pages to check if the user is authenticated and redirect to the login screen if not. I use the Navigation framework so I have a Frame - this may make it easier...
Any tips or pointers appreciated - I just need some ideas to get started please.
Just store the fact that the user is authenticated anywhere you like - I tend to like the Application object since it's an app-wide setting, but you can stick your "IsAuthenticaed" and/or "Roles" properties anywhere, really.
Take a look at WCF RIA Services - even if you don't want to use their solution, you can take a look at the generated authentication code it makes and see a good real-world example of how this can all work.
As for redirecting if the user is not logged in, I suggest using an INavigationContentLoader on your Frame, which can implement this logic in a central location. See these two excellent posts by David Poll on the subject of INavigationContentLoader and authentication/authorization:
http://www.davidpoll.com/2010/01/01/opening-up-silverlight-4-navigation-authenticationauthorization-in-an-inavigationcontentloader/
http://www.davidpoll.com/2010/05/10/common-navigation-ui-and-authorization-driven-sitemaps/
Is there any problem with security if I store userid,profileId,username and other such kind information in cookie.
Yes there will be an enormous security problem doing this. If you don't encrypt the cookie anyone could replace the username you've stored with say for example Administrator (usually id=1) and send a request to the web server.
This information need very often,and instead of do Sql query every time I can one time get this information from Sql,store it in cookie(when user login) and then get it from cookie.I think it will be more efficient.
Yes, you can do that BUT ONLY IF IT IS NOT CRITICAL THAT THIS DATA BE CORRECT.
The user can edit his own cookie.
If he wants to change his display name to something else, or get a different background picture, probably no problem.
If he can impersonate other users, big problem.
So, to be on the safe side, better not go down this road.
If you need performance improvements, consider server-side caching solutions instead.