We are using an Http Module. In the http module we are setting a cookie. After that in the page we are trying to take the value from cookie.
So when we are requesting a page, first the code inside http module will execute and it will set the cookie and then the value can be taken from cookie in the page load of the page.
But while debugging the code in Visual studio, we found that if browser cookie is disabled, then in the httpModule it will try to set the cookie and after that in the page load if we check the request object, it is showing the cookie set from the httpModule.
Is this a correct behavior? I want to know whether cookie is disabled in this case. If it is diabled i want to take another value from db. But it always showing the value in cookie.
Can anyone please suggest a method to get whether cookie is disabled or not.
We are using the httpModule in an Umbraco site.
I would write a cookie and then do a redirect to check if that cookie exists if it does then you know cookies are enabled if not then cookies are not enabled. Here is a good example.
http://www.primaryobjects.com/CMS/Article54.aspx
Related
I am fairly new with developing in ASP.Net and I've searched high and low for a resolution to this, to no avail. I am using Forms Authentication to authenticate users and when I login with user A, I abandon the current session, generate a new session cookie/id and redirect from to my content page and everything works as planned. However, when I open a new browser window and navigate to the login screen, thus starting a new session, the authentication cookie for user A is automatically passed to this session and is part of the request cookies collection. Even worse, when I actually log in as user B and get a new authentication cookie then refresh the browser window for session A, it now has the authentication cookie of user B.
I have no idea why this is happening. I thought the browser (IE9) was caching the authentication cookie because the response-header collection is set to cache-control "private" even though I specifically set the Response.Cache.SetCacheability("no-cache") in my code-behind for all pages. Then I was thinking it could be a threading issue.
Any insight into why this is happening is greatly appreciated, Thanks.
Try different Browsers like Chrome and IE. Because browser share same cookie and temp file even opened in new windows. Above scenario will occur if you try with gmail.com or live.com.
Check your web.config files for session settings.
Check out the following link:
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.enablecrossappredirects.aspx
I have an asp.net website located on some server.
I try to login the website using IE10 compatibility mode, I fill user name and password, and when I press on the "Login" button, nothing happens. I get the login page again.
I checked with wireshark and found out that the cookie is not passed when redirecting from the login page.
I tried the workarounds from this post:
IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
I checked that the date and time of the server are equal to the date and time of the browser, and my server name doesn't contain non alphanumeric characters.
I tried changing the browser settings, restore to default and I tried with or without compatibility mode, but nothing helps!
(in chrome everything works fine and the cookie is passed).
Does someone have an idea about that?
Still cannot post comments...
You can always use cookieless="AutoDetect" to use Uri instead of cookies if it cannot set cookie. Some user may even deny all cookies, that is why all advertisements use only Uri mode.
Though it might result in share of Uri (easier than to share cookies) and if a user shouldn't be allowed to login from different places at once you'll need to revise your login logic.
I have a complex URL rewriting scheme which breaks the built in Forms Authentication ReturnUrl mechanism. I would like to grab the requested URL for later redirection away from my login.aspx. I can get this URL in Application_BeginRequest via HttpContext.Current.Request.AppRelativeCurrentExecutionFilePath. However, Session state is not available in Application_BeginRequest. How can I store this URL prior to ASP.NET redirecting me to login.aspx?
Are client cookies an option? Without an available session state, I don't believe you have any server-side choices.
You could use a static. However, you'll need something to key it to each user (e.g. user name, session identifier etc.). If you have to do it before the user is logged on, your only option is to stuff some sort of identifier into a cookie at which point you might just want to put the whole URL there.
In config file I have the below settings
sessionState mode="InProc" cookieless="false"
Does this indicates that the sessionid is stroed in cookies? If yes then how is it picked and sent to the server and how is it verified across postbacks.
What will happen if cookies are disabled in my browser, will the session(sessionid and session variables) still be created?
Where(default path) are the cookies created and stored by default for sessions and can i change the path?
What format and kind of data is stored in cookies for session?
If i store a class object in session then what is actually stored in cookies?
Also if i use authentication mode as forms with cookies then what will happen if cookies are disabled in browser?
The session cookie is a special non-persistant cookie. It's only stored in memory, so in most cases even when cookies are disabled it still works fine.
It's also possible to enable something called cookieless sesssions where the sessionID is embedded in the URL, like this:
http://yourserver/folder/ (encrypted session ID here) /default.aspx
Here's a link to an MSDN article with more details: http://msdn.microsoft.com/en-us/library/aa479314.aspx
NOTE: It is possible to completely block the session cookie. For instance, in IE8, I just went into Tools > Internet Options > Privacy. When I cranked the slider up to 'High' or greater, my sites never got past the login screen because the session cookie was blocked - in fact, Josh Stodola said below that in this case the session would never even be created on the server.
However, understand that this type of behavior effectively breaks the Internet. So unless you're building a site targeted at conspiracy theorists, in my opinion (and the opinion of most of the largest sites in the world) there's no need to cater to the tiny percentage of users who don't play by the normal rules.
For them, the Internet just isn't going to work the way it's supposed to.
My guess is that each request by the client will be seen as a new session by the server.
If you happen to grab the request headers from your browser, you can see that a SessionID is part of the header. This is used by the server to determine which session belongs to which user.
Instead of session id being passed via cookie, it is typically passed as a query string in the URL, or as a custom HTTP header. With the scenario you described, however, your user will never obtain a session because you have cookieless set to false.
I have not implemented this personally. But it should be like:
As Cookiless=false in web.config file and browser has disabled cookies, when first request for the page comes, HTTP module will check for forms authentication cookie. Now it will be empty which send user to login page. Now when second request for any page on website will come it will again find forms authentication cookie empty and send user to login page. So for every request user needs to create new session.
No, If cookies are disable the session will not work.
if you want to use session when cookies disable then you can pass session thru URL.
It stores directly in the browser
There are two ways session state can store the unique ID that associates client with server session; by storing an HTTP cookie on the client or by encoding the session ID in the URL.
Session Mode="InProc" is a default mode which stores the session state information in web server. However when you say cookieless="false" you are saying to stored unique ID in cookie. This Id is created when session is created, so during postback ID is picked up from cookie. If cookie are disabled in browser,yes session still will be created and this id is passed along URL.
You can browse to cookies by going to browser settings->Privacy->Content Settings->All cookie and site data->Stored with site name
Probable you might find cookies in %userprofile%\AppData\Roaming\Microsoft\Windows\Cookies but might differ from operating system to system.
In cookies you usually store small piece of insensitive personal information. If you need to store sensitive data such as user name and password it is better to encrypt those data.
In cookie you usually store information about the users. For more details please visit URL
http://msdn.microsoft.com/en-us/library/system.web.configuration.sessionstatesection.cookieless(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/ff647070.aspx#pagexplained0002_cookielessforms
The question that I have is very basic: Is there a way to inform the web browser that the content of the cookie has changed?
I don't want to keep looking at the file and check if it has been updated because it'll cause performance degree on my app.
Thanks in advance!
It's always the job of the server to "push" the new cookie to the browser (in ASP.NET, by setting Response.Cookies("cookie_name")).
I'm not sure to understand your concern, only your application can know that the user's cookie needs to be changed, but it's usually not stored as a file on the server.
You would probably have to check for the Cookie or Set-Cookie http headers that come with the ASP page whenever it reloads in your application, though this would not account for changes made by javascript.
If the ASP page is refreshing each time a cookie changes, that is likely to be a much larger overhead than the WPF reading the cookie from the disk.
Well, since the ASP page needs to be active in order to SET the cookies, why couldn't you just use a HttpClient to request the cookies in your WPF app and on the server, set the cookies. Then send HTTP Response depending on whether or not you set the cookies. If you receive a 200 OK response, you can know your cookies are set. If there's an error, send a 500 Server Error back.