I'm designing a single page web application with all the action happening on default.aspx. I store the user's user id in Session after he logs on. I use SWFUpload in default.aspx to upload files to upload.aspx.
When upload.aspx receives a file, it checks HttpContext.Current.Session for the user's id. This used to work, but since recently HttpContext.Current.Session doesn't have any values regarding my session. I must have changed something along the line but I have no idea what.
Stranger still, it still works with IE, but not with either Firefox or Chrome. I also read something about Flash in Firefox mistakenly uploading IE's session cookie (I'm paraphrasing).
How do I retrieve the Session data from the upload page (Firefox and Chrome)?
This is a known issue with Flash and cookies on non-IE browsers. Here's a post over at swfupload.org that discusses a workaround, and 'just the code' over at snipplr. Basically Flash does not send your cookies (or sends IE cookies) on Firefox and Chrome, etc., so your SessionID is not sent with your upload.aspx request in those browsers. In IE it will work, though.
The workaround above is to send the SessionID and Authentication ticket in the post or url, and then in the Global.asax intercept the request and recreate the correct cookies before ASP.NET looks for them in order to retrieve authentication or session information.
Related
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 an application in ASP.Net that use cookies for store some information.I want to open a form only first time when a user enter into the site.I created a cookie and I wrote something in that .The next time I enter the site, I read this information,if something is wrote in there that means that it's not necessary to open the form again.It works fine if I use the same browser, but if first I open with Internet Explorer the site ,I make the cookie , wrote something in it , I close the browser and then I open site with Mozzila Firefox the application can't see the cookie that i created with Internet Exlorer(the read cookie is null) .I create the cookie with Mozilla , i open application with Chrome , this also doesn't see the cookie.If I wrote something in the cookie with one browser , I can read this value only if i use the same browser. What should I do to see cookie content with all the browsers, to can read the cookie content with all browsers?
No! You can't and Check this question Can two different browser share on cookie?
That is not possible with regular cookies, what I know of. Each browser store and keep track of their own cookies, and does not share them.
I haven't tried it myself, but there are examples where Flash cookies and JavaScript are being used to create something like a cross-browser cookie.
I am a bit confused on how ASP.NET session works with my site, when a user opens up the site in multiple browsers, and/or multiple tabs.
I see that after logging in with IE, i can open a new tab and not have to log in, and that if I log out of one tab, the other one will redirect to login after I try to do something.
I also notice that if I log in with IE, i still have to log in with FF.
My question - are session data shared between all of these sessions?
Are there any concerns I need to take into account here?
Thanks!!!
Sessions are cookie-based; so they will not be shared by different browsers (eg. Firefox vs IE), but they will be shared between instances of the same browser (eg. multiple tabs/windows of IE).
In your case, the login (authentication) information is stored in a cookie. Therefore, if you login using IE then the cookie is only for IE and you would have to login again with a different browser or when the cookie expires.
You have to log in with each browser so they can each create/write the login cookie. Once they have cookie you shouldn't have to login until it expires or you log out, which should include additional tabs.
I have an ASP.NET web application that, for whatever reason, when it is deployed on any IIS server, will behave like the pages are cached and it simply never posts back to the server.
For example, navigate to the login page, enter credentials, click the login button, and it's back to the login page you go, with the form fields cleared. The information is not getting submitted back to the server. The postback is not executing. It seems the browser is simply restoring the original page from cache.
I found this article that says I need to put something in the ASP.NET session state in order for the session to remain valid.
When a user connects to an ASP.NET
application, a unique session ID will
be affiliated with the user. If
nothing is put in the session however,
no cookie will be sent to the browser.
This means that the user will get a
new session ID the next time a new url
is open or the page is refreshed. If
something is put on the session
(HttpContext.Current.Session["Hello] =
"hello") however, ASP.NET will issue a
cookie called ASP.NET_SessionId. This
cookie contains the user's session ID
and the cookie will expire at the end
of the session (when you close your
browser).
I will try what that article recommends, as I had not been storing anything in the session.
I have also added expiration headers to the page:
Response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1))
Response.Cache.SetCacheability(HttpCacheability.NoCache)
Response.Cache.SetNoStore()
and put some meta tags in the html:
<meta http-equiv="pragma" content="no-cache" />
<meta http-equiv="cache-control" content="no-cache" />
Any other ideas as to what the cause of this behaviour may be?
The issue was related to IIS.
The Directory Security for the web application was set to run only under anonymous access with a local user account and application pool specifically created for the application.
Turns out, Integrated Windows Authentication and Enable anonymous access must both be checked otherwise you'll get this weird behaviour.
FWIW, the ASP.NET web application is running in a FRAMESET/FRAME under a classic ASP site and the issue only occured when accessing the site from the local network. It worked fine externally. It also worked on the local network the first time it was accessed, then the session cookie would need to be cleared for it to work again.
This does not sound like a session state problem. It sounds like a problem with your Sub Page_Load
Is it just the login page that this happens to? If you've tried this on several IIS servers it would seem that something in your page is off. A standard install of IIS and a simple ASPX page with a button will cause a postback without having to do anything at all. If you aren't seeing that, then it must be something on that page. Try creating a very simple page with just a label and button and verify that you can see the post back and the page_load (like RichO said) are working correctly.
What sort of server configuration are you you using? It's a long shot, but sessions are server-specific: if you have multiple web servers, subsequent page loads may behave (correctly) as if the session was never set.
Make sure you have cookies enabled in your browser. Session storage requires cookies.
If this is happening on your dev box, set a breakpoint in your page_load (assuming you're not using MVC) or your POST controller action to see what's actually happening server side.
Also, try hitting this through an HTTP sniffer (like Fiddler) to see what's going over the wire.
I have a Drupal site with user logins. Embedded within this site is a Flash application that shows some data to everybody but allows extra functionality if the user is logged on. From within Flash, I'm using XMLRPC to access the system.check method (to determine whether the user is logged in) and the user.login method (to log in a user from within Flash).
Within Flash, everything works fine. However the Flash login state does not seem to correspond to the rest of the site. For example, if I invoke user.login via XMLRPC, subsequent calls to system.check show that I am logged in, but the Drupal user page still says I'm logged out. Or if I am logged in both places and then I log out via the Drupal user page, the next call to system.check still indicates that I am logged in.
How can I make the login state consistent between the Drupal GUI and my embedded Flash app?
(Note: I am not using any XMLRPC library, I am just constructing the requisite XML manually and sending POST methods using a URLRequest object.)
EDIT: I have confirmed via this question and also via testing with a Web Proxy that the SESS cookie returned by the user login page is being picked up and sent back by the flash application.
EDIT: And now I have shown experimentally that even though Flash (via Safari) is sending the same cookie, it gets back a DIFFERENT cookie when it connects to the XMLRPC service than when it requests and HTML page. In other words, Drupal just doesn't support this kind of synchronization and I'm stuck. I'm accepting the answer below that put me on the right track.
EDIT: AMHPHP is not fully released for Drupal6 as of this writing, but it turned out to be installed on the site anyway. Using the DrupalSite library, I was very easily able to log into and out of the site from flash, and the login remained consistent between flash and HTML.
I'm not terribly familar with Flash, but do the URLRequest objects "inherit" state from the browser session, including the user login cookies? If not, you'll need to explicitly send the login cookie with your hand-built request or Drupal will think that it's just coming from another web browser at the same IP address.
If you're not quite sure, using the Firebug plugin might be useful. It lets you inspect any requests that are being piped through the browser, examine their headers, and look at the raw HTTP response object that comes back.
Update: Even more important than the flash widget getting a session cookie is the flash widget getting the SAME session cookie as the web browser itself. Drupal allows users to log in from multiple machines simultaneously, so if the browser is creating one session and the flash widget is creating another, you'd see the behavior you're describing...
It can't be done.
(For details, please see my final edit to the original question and the equivalent information in my comment to #Eaton.)