I have a page A which generates another page B's URL with a query string containing encrypted authorization information to access to that page B.
When a user use that URL to access to the page B, I want to write a cookie with the authorization information into the user's local machine.
I read the MSDN reference and it does mention cookies can be generated and read through request and response, but is there a way to write the cookie to a specific location?
Is there also a way I can check whether there's already an existing cookie in the user's local machine before I generate my cookie.
Thanks in advance.
There is no way to check nor set cookies that are not under the same domain as the site performing the request.
You can only set or read cookies for the Same Origin as the site that is the setting the cookie. This is a security feature built in to HTML and can not be worked around.
For a easy to understand example of why this is this way, would you like www.myEvilSiteThatStealsYourData.com to be able to read or write cookies for www.theBankingWebsiteYouUse.com?
Url in page A should contain encrypted UserID and Timestamp symmetrically encrypted ,(like /B?SecurityToken=blabla), page B has to decrypt the security token, verify Timestamp is not too old (1 minute should be enough) and create cookie based on decrypted security token.
More robust scenario: A (identity provider) send user to B (service provider) without any token whatsoever; B checks if user have authentication cookie in B domain, if he does not, B redirects user to A's single login handler, if user have authentication cookie in A domain, A sends encrypted response to B, providing info about user (like UserID) otherwise A asks user for credentials, and if they're correct A sends encrypted response to B. B decrypt the UserID and creates authentication cookie in B domain. There are also protocols for this (SAML, OAuth) - in similar way you can use facebook or google to do identity provider for your app.
Related
I am using forms authentication to handle SSO across *.mydomain.com
Upon login i create a non-persistant cookie with the ticket embedded in it and set it's domain to .mydomain.com.
However the problem is that when i visit any website on the domain, i find there are two cookie with the same name but with different domains. :
1> site1.mydomain.com [1st Forms Auth Cookie] duplicate cookie
2> .mydomain.com[2nd Forms Auth cookie]
The 1st Cookie is not created by me.Also it isn't secure.
Upon logout i successfully clear my 2nd Cookie.
However, the 1st cookie remains and for a user it appears that he is still logged in to site1 . This happpens because i check for the existence of the cookie with the same name and surely the 1st cookie is wrongly assumed to be the Forms Auth Cookie. I cannot check the domain property because in the Request the information about the domain is null .
My issue is how is the second website-specific domain cookie is getting created.
If i cannot avoid this, is there a workaround?
UPDATE : The encrypted value stored by this faulty cookie is updated on each request i make on the website,while the encrypted value in my Auth Cookie remains same
According to MSFT Docs
"The Add method allows duplicate cookies in the cookie collection. Use the Set method to ensure the uniqueness of cookies in the cookie collection."
After renewing my Forms Authentication ticket i was doing :
Response.Cookies.Add(..);
Thus a new duplicate cookie was getting generated.
To fix this do :
Response.Cookies.Set(..);
If you were like me you would have expected ASP.Net to replace the old cookie with the new one.
I have one site - account.mysite.com which only register/login users in my system.
I want to check user's email and passwords in one site and send something to another site, which definitely determines who login.
Can I use FormsAuthentication?
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(name, true, 60);
string encrypted = FormsAuthentication.Encrypt(ticket);
return "mysite.com?" + FormsAuthentication.FormsCookieName + "=" + encrypted;
Or do I need to use some features from aspNet.Identity? If yes, how I can do this?
Thanks.
If you're using MVC 5, then you should also use Identity. However, whether you use ASP.NET Membership (forms auth) or Identity has no bearing on any of this.
Simply, in either scheme, an auth cookie will be set. This is what determines a user's "logged in" status. With each request, the user's browser will send the cookie back to the server, and the server will validate it and either consider the user authenticated or not as a result.
So, this all boils down to making sure that auth cookie is shared between your different sites and can be read and validate by each of your sites.
On the first part, cookies are restricted by domain. If the cookie is set on account.mysite.com then it will only be sent to account.mysite.com. However, you can set it as a wildcard, so that it will be sent to anything on *.mysite.com. That then would allow account.mysite.com to set the cookie and still have it be sent to something like subdomain.mysite.com. If you have completely different domains in play though, like account.mysite.com and you want that to log you in at foo.com, that's not possible. The only way to handle that situation is set up a SSO implementation which is non-trivial and far beyond the scope of what can be reasonably answered here. There's entire companies devoted only to setting up SSO for organizations.
So, assuming you're not dealing with different domains and you can at least get each site to get the same cookie, then next part is unencrypting that cookie. The auth cookie is encrypted before it is set, so it can only be read by a site that knows how to decrypt it. The encryption is based on the machine key, so essentially, all your sites need to share the same machine key. For more information, see: https://technet.microsoft.com/en-us/library/cc755177(v=ws.10).aspx
I have a website with two different domain.
us.site.com
usa.site.com
Now when user Click on Login
It first check its country. According to country I want to redirect whole site on that url and that time it not again asks for account id and password. so i want to maintain these things but it should not visible in Url.
Please Suggest me any way to do this.
I don't want to use QueryString and Cookie
Posting my comment as an answer.
Basic idea as following. You can use cookies. On login, create a cookie for "site.com" having user information. When user redirects to for say login to usa.site.com, check the cookies in pageload. If you found the cookies read the cookies and convert it to session. Use session further to check loogged in user information.
Related question link,
How can you keep a session across multiple subdomains in c# mvc?
How can I share a session across multiple subdomains in ASP.NET?
Write cookies from subdomain and read from another subdomain without changing web.config
To make cookie secure use encryption.
Reference :
http://www.codeproject.com/Articles/13665/HttpSecureCookie-A-Way-to-Encrypt-Cookies-with-ASP
Encrypt cookies in ASP.NET
http://www.c-sharpcorner.com/UploadFile/manishkdwivedi/encrypting-and-decrypting-cookies-in-Asp-Net-2-0/
Use MD5/SHA Encryption to store value in cookie and once you redirect to other page then use decryption Algo and use that cookie value.
It will solve your issue.. Check below link for reference -
http://www.codeproject.com/Articles/38951/How-To-Hash-Data-Using-MD-and-SHA
http://www.codeproject.com/Articles/14150/Encrypt-and-Decrypt-Data-with-C
http://www.codeproject.com/Articles/12602/Using-MD-Encryption-with-C-and-MSSQL
Or you can use alternative way to store value in database temp table
I have a primary web app with authentication on example.com, and I have a secondary app with authentication on subdomain.example.com
I want the 2nd app to be integrated with the first one. So once a user registers and logs in, s/he doesn't have to register/log in again.
It is possible to send a post request, but this won't generate the cookies in user's browser...
How can I do that?
Thanks
You're able to set a cookie so that it works on all subdomains (www, subdomain, etc.). See Basics of Cookies in ASP.NET:
By default, cookies are associated with a specific domain. For example, if your site is www.contoso.com, the cookies you write are sent to the server when users request any page from that site. (Except for cookies with a specific path value, as I explained in the section immediately preceding.)
You can also use the Domain property to create a cookie that can be shared among multiple subdomains. For example, set the domain as follows:
Response.Cookies("domain").Value = DateTime.Now.ToString
Response.Cookies("domain").Expires = DateTime.Now.AddDays(1)
Response.Cookies("domain").Domain = "contoso.com"
The cookie will then be available to the primary domain as well as to sales.contoso.com and support.contoso.com.
What is the difference between a Session and a Cookie?
What circumstances should each be used?
Sessions
Sessions are stored per-user in memory(or an alternative Session-State) on the server. Sessions use a cookie(session key) to tie the user to the session. This means no "sensitive" data is stored in the cookie on the users machine.
Sessions are generally used to maintain state when you navigate through a website. However, they can also be used to hold commonly accessed objects. Only if the Session-state is set to InProc, if set to another Session-State mode the object must also serializable.
Session["userName"] = "EvilBoy";
if(Session["userName"] != null)
lblUserName.Text = Session["userName"].ToString();
Cookies
Cookies are stored per-user on the users machine. A cookie is usually just a bit of information. Cookies are usually used for simple user settings colours preferences ect. No sensitive information should ever be stored in a cookie.
You can never fully trust that a cookie has not been tampered with by a user or outside source however if security is a big concern and you must use cookies then you can either encrypt your cookies or set them to only be transmitted over SSL. A user can clear his cookies at any time or not allow cookies altogether so you cannot count on them being there just because a user has visited your site in the past.
//add a username Cookie
Response.Cookies["userName"].Value = "EvilBoy";
Response.Cookies["userName"].Expires = DateTime.Now.AddDays(10);
//Can Limit a cookie to a certain Domain
Response.Cookies["userName"].Domain = "Stackoverflow.com";
//request a username cookie
if(Request.Cookies["userName"] != null)
lblUserName.Text = Server.HtmlEncode(Request.Cookies["userName"].Value);
sidenote
It is worth mentioning that ASP.NET also supports cookieless state-management
Cookie is a client side storage of your variables. It stored on client machine by browser physically. It's scope is machine wide. Different users at same machine can read same cookie.
Because of this :
You should not store sensitive data on cookie.
You should not store data that belongs to one user account.
Cookie has no effect on server resources.
Cookie expires at specified date by you.
Session is a server side storage of your variables. Default, it stored on server's memory. But you can configure it to store at SqlServer. It's scope is browser wide. Same user can run two or more browsers and each browser has it's own session.
Because of this :
You can save sensitive data in session.
You should not save everything in session. it's waste of server resources.
After user closes browser, session timeout clears all information. (default is 20 minutes)
A cookie is an identifaction string stored by a server (who has a domain) in the browser of the user who visits the server/domain.
A session is a unit of maybe variables, state, settings while a certain user is accessing a server/domain in a specific time frame. All the session information is in the traditional model stored on the server (!)
Because many concurrent users can visit a server/domain at the same time the server needs to be able to distinguish many different concurrent sessions and always assign the right session to the right user. (And no user may "steal" another uses's session)
This is done through the cookie. The cookie which is stored in the browser and which should in this case be a random combination like s73jsd74df4fdf (so it cannot be guessed) is sent on each request from the browser to the server, and the server can assign and use the correct session for its answers (page views)
The cookie allows the server to recognize the browser/user. The session allows the server to remember information between different page views.
Sessions are not reliant on the user allowing a cookie. They work instead like a token allowing access and passing information while the user has their browser open. The problem with sessions is that when you close your browser you also lose the session. So, if you had a site requiring a login, this couldn't be saved as a session like it could as a cookie, and the user would be forced to re-login every time they visit.
Its possible to have both: a database primary key is hashed and stored in a lookup table: then the hash is stored on the client as a cookie. Once the hash cookie (hahhahaha :) is submitted, its corresponding primary key is looked up, and the rest of the details are associated with it in another table on the server database.
The main difference between cookies and sessions is that cookies are stored in the user's browser, and sessions are not. This difference determines what each is best used for.
A cookie can keep information in the user's browser until deleted. If a person has a login and password, this can be set as a cookie in their browser so they do not have to re-login to your website every time they visit. You can store almost anything in a browser cookie.
Session is a server side object,
which transfer or access data between page call.
Cookies is a object which is client side/client machine which store some text information of browser and server.
There appears to be some confusion regarding what a session cookie is.
Firstly, when we are talking session cookies - it has nothing to do with ASP.Net sessions. Likewise, session cookies have nothing to do with server side processes or caching.
A session cookie is nothing more than a cookie that expires when the browser session expires. To create a session cookie - don't put an expiration date on it. Doing this stores the cookie in memory and is disposed of when the browser is disposed.