This may or may not be a programming question, but one or two users of my website have got some strange strings being inserted into their address bar.
The address should be:
http://URL/Couple of Folders/page.aspx
but occassionally the same thing becomes:
http://URL/(X(1)F(qHfgTf50ahMY47b-lnz3ovk89OA4AbMN4S-sYVZCgCULL))/Folders/Page.aspx
The string is also in the action field as so:
<form name="aspnetForm" method="post" action="/**(X(1)F(qHfgTf50ahMY47b-lnz3ovk89OA4AbMN4S-sYVZCgCULL))**/<Page>.aspx" onsubmit="javascript:return WebForm_OnSubmit();" id="aspnetForm">
I'm no server/IIS expert, so please excuse me if this is a dumb question, but what is the strange string and do I/my clients need to worry?
Looks like you have cookieless sessions set to auto in your web config.
If a user allows cookies, their sessionID is stored in an in memory cookie. If they don't, ASP.Net pushed the sessionID into the URL, and this is used to identify which user is making the request. The strange string of characters you are seeing are sessionIDs for those people who have cookies switched off.
There's not really anything to worry about here, although it does make session hijacking a little easier... Probably wouldn't stress about this though.
Hope it helps...
Please check your sessionstate node settings in web.config. The cookieless attribute in sessionstate node must be set to false as shown in the following settings.
<sessionState mode="Off|InProc|StateServer|SQLServer"
cookieless="true|false"
timeout="number of minutes"
stateConnectionString="tcpip=server:port"
sqlConnectionString="sql connection string"
stateNetworkTimeout="number of seconds"/>
Paul is correct about the sessionID being pushed into your URL's for cookieless users. This is not a problem for human users but poses a potentially significant challenge to bots (most significantly Googlebot's spider) who are crawling your site to index and rank your site in search engines.
Bots will be identified as cookieless by your ASP.NET framework which causes a couple of 302 redirects from the ://URL/autocookiesupportdetect then to the URL/(sessionID)/folders... This 302 redirect is bad enough but, to make matters worse, Googlebot receives a sessionID each time it crawls your site and views each URL with the sessionID as a duplicate page to index. This hurts the pagerank for each page Google crawls with the session ID in the URL.
The fix is add a definition file to your site to identify bots as accepting cookies thus serving them a cookie (vs. a cookieless) session. You then will not have to require that your human visitors have cookies enabled and your bot vistors will be happy to see your pages without the sessionID in your URL's.
Related
I have two domains. Something like:
1) www.mydomain.com
2) www.mydomain.virtual.com
Temporarly, i must redirect Domain 1 to Domain 2, so when someone use www.mydomain.com y redirected him to www.mydomain.virtual.com.
The problem I'm facing is that (only on internet Explorer) session object is now losted between my sub-pages inside my web. I créate a session on default.aspx, and when i redirect with response.Redirect to let's say main.aspx, the object has no value. Does anyone have any idea why? Thanks!
Sessions are stored on the server, but the client needs to keep track of the sessionid. Usually a session cookie is used to store the sessionid.
What is causing this behaviour is that the sessionid cannot be resolved. Probably because the domain name is different and the browser interprets this as a third-party cookie, which can be (and probably is) blocked by the browser.
Since the sessionid cannot be resolved, all session info on the server is inaccessible. The link is broken.
Is it an option to copy the entire website to the temporary location and redirect all calls made to the original website to the equivalent page on the temporary location?
Otherwise you can solve your issue by using cookieless sessions:
https://msdn.microsoft.com/en-us/library/system.web.configuration.sessionstatesection.cookieless%28v=vs.110%29.aspx
For more information concerning cookies:
http://erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains/
Afternoon Folks,
I was wondering if anyone could give me a heads up with regards to this problem that I'm having. I'm not positive on what I should be seeing I suppose is the main issue that I'm having.
I have changed the web.config to use the following:
<httpCookies requireSSL="true" />
All works fine for the general cookies defined when I make a request over http (as opposed to https) in that they don't appear, however the asp.net_sessionid cookie ( ASP.NET_SessionId=epg3ebjv1hheqe45kgp0j055) still appears. Is this correct behaviour, should it not be missing?
UPDATE:
While doing a bit more trawling through the internet I discovered that this is only applicable to forms cookies. It doesn't apply to session cookies. Sickner! However, the following link suggested a fix for it: How to secure the ASP.NET_SessionId cookie?
Which did not sort out my issue unfortunately, the cookie still appears in the request.
The cookie will always appear. If it's secure the content will be encrypted (and it will be transmitted in an encrypted fashion if you're using SSL.
That session ID has to be sent somehow. If you'd rather not have it stored as a cookie, you may want to look into cookie-less sessions. In that case, the session will be part of the URL construct.
Maybe try setting a custom cookie name and using the workaround you found?
I have a classic asp website that uses Session variables to store login state ie. userid, isloggedin, etc. On logout, the session variables are reset and Session.Abandon() is called followed by a redirect to the login page. In IE7 I have noticed that after logout I can type in a previously visited url and see what appears to be a cached version of its state prior to the logout. Hitting ctl-f5 will reload from the server again and redirect to the login page. This is the behavior I want to occur even if the url is type in without the ctl-f5. Does anyone know how to get this behavior?
set the no-cache headers so that the pages do not get cached in the first place. see:
http://support.microsoft.com/kb/234067
I think mkoryak's answer (using no-cache headers) seems best. If you want certain pages to be seen only when a user is logged in, the best way is to instruct the browser to simply not cache the page. Furthermore, schemes such as tweaking cookies and using javascript do determine login state on the client are simply reinventing the wheel.
If you want to leverage some caching and your page isn't something that is constantly updating, a good compromise is to set the Response.Expires header to some value you deem appropriate (it's measured in minutes I believe).
I've had a similar problem before, but whenever I've clicked a link on that page, it's asked me to log back in.
You could try either resetting sessionID = "" or sessionID = "XYZ" and make XYZ something your code ignores on log out.
You could also try setting no-cache headers.
You could send no-cache however thats quiet a performance hit just to get what you want. I prefer Liams suggestion and ensuring that everything you do from that page requires you to be logged in, that way no one can do anything they shouldn't. What if its a email system though or similar, the people "could" view other peoples emails which are cached, in those instances then yes, not caching sensitive information is the way to go (you can't cache HTTPS pages by default for instance).
You could also include some javascript in the head which could check for the existance of a "logged in" cookie. This would run every time they loaded the page, if no cookie exists then JS could redirect you off to the login page. Not 100% fool proof but good enough. You logout page would need to clear this cookie and you login page set it.
While I realise that this is usually related to cross site scripting attacks, what I'm wondering is how can a session remain valid throughout multiple subdomains belonging to a single domain (example: a user logging in only once, and being able to access both subdomain1.domain.com and subdomain2.domain.com with the same session). I guess I first need to understand how it works, but so far I haven't been able to find much that would be of any relevance.
But then again, maybe I wasn't asking the right question.
Thanks in advance :)
Inproc sessions cannot remain valid, however you can code your web application to allow cookies across multiple subdomains. You will need to set the domain equal to:
Response.Cookies("CookieName").Domain = ".mydomain.com"
Remember the period.
There are quite a few ways to share session data or cookie data across domains. The simplest is to share it on the server side through a shared data store. But you would not be asking this question if it were that easy.
The other way to do this is equally simple. The domain one.com contains some session data say name=aleem and id=123 and wishes to pass this along to two.com. It will follow these steps:
Make a call to two.com/api/?name=aleem&id=123
When two.com gets the data via query parameters, it creates a cookie with the data. This cookie will be stored under the two.com domain.
two.com will then redirect back to the REFERER which in this case happens to be one.com
This is a simplified scenario. The domain two.com needs to be able to trust one.com and not only that but it needs to know that the request is authentic and not just crafted by the user so you need to use public/private keys to mitigate this.
By default, all cookies for a site are stored together on the client, and all cookies are sent to the server with any request to that site. In other words, every page in a site gets all of the cookies for that site. However, you can set the scope of cookies in two ways:
Limit the scope of cookies to a folder on the server, which allows you to limit cookies to an application on the site.
Set scope to a domain, which allows you to specify which subdomains in a domain can access a cookie.
You can learn more here.
The comments about the cookie being set for the domain to allow subdomains to receive that cookie give you that side but what's missing is the consistency of session.
I think this is very much like the problem of maintaining state across servers in a farm and the solution is probably to ensure that your session store is consistent across both sites (if they are not server from the same 'web site' in IIS). You can move the Session store into SQL Server (HOW TO: Configure SQL Server to Store ASP.NET Session State) which would probably serve the purpose as each site would query the same store when looking for the session data related to the cookie they've been presented with.
I hope that gets you on the right track.
If you have the ability to set up a common subdomain, you can do this:
In your subdomain html files, include a javascript file at the top like this:
<script src="http: //common.domain.com/check.asp"></script>
In check.asp, look for your logged_in cookie and if not present, show a page say, http://common.domain.com/login.asp using something like
<%
if (cookie_not_found){
%>
location.href = "http: //common.domain.com/login.asp";
<%
}
%>
Once a person submits username password, submit it back to the same login.asp and set the session cookie, (which will be set in common.domain.com domain) and then redirect to http://subdomain1.domain.com.
What will happen now is, a call will be made to the embedded "common.domain.com/check.asp", and cookies for common.domain.com will be sent by the browser along with the request. So you will know whether your session is valid or not, even when you are in subdomain1.domain.com.
You can set a cookie for a specific domain.
In php, the setCookie() method contains a parameter in which you can specify the top-level domain, so the cookie is valid for all subdomains. Based on your tags, I see you are working in asp.net. Probably this also exists for asp...
after a little search for asp:
try this:
Response.Cookies("CookieName").Domain = ".mydomain.com"
or read this
Here is a solution which works:
http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
I have a web app that is being hit by facebook. The login page retrieves the keys that I need and sets some session variables. When the server then redirects the user to the next page, the session information is lost. I’m running the IIS engine on vista ultimate at the moment, the app pools don’t matter because I’m using a state service and I’m still losing the session state. I’ve tried both the overloaded method of the response.redirect function and also adding a header to the page to force the redirect and none of this seems to work. Does anyone have any ideas of what I’m missing?
I’ve tried both of these:
Response.Headers.Add("refresh", "3;url=Dashboard.aspx")
And
Response.Redirect("Dashboard.aspx", False)
[EDIT]
So i just did a little experiment and well it turns out that when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
[EDIT]
So I found an article on this and after addin gthe header the problem was solved (for now)
http://support.microsoft.com/kb/323752
Response.AddHeader("P3P: CP", "CAO PSA OUR")
when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
If you're in an iframe, any cookies you set are “third-party cookies”. Third-party cookies may be subject to more stringent conditions than the normal “first-party” cookies you are setting when the user is directly on your site. This can be due to different browser default cookie handling or because the user has deliberately configured it like that. (And for good reason: many third-parties are unpleasant privacy-invading advertisers.)
In particular, in IE6+ with the default settings, you cannot set a third-party cookie unless you write a P3P policy promising that you will be a good boy and not flog your users' data to the nearest identify thief.
(In practice of course P3P is a dead loss, since there's nothing stopping the site owner from just lying. Another worthless complication that provides no actual security. Yay.)
I'd try running Fiddler and see if your session cookie is being sent properly with the response when interacting with your app via Facebook.
The session depends also on cookie support by the client. When you say the app "is being hit by facebook" are you sure that by what ever means they are "hitting" you they are supporting cookies?
Response.Redirect and refresh don't carry session. Server.Transfer() can but loses the ability to transfer to other servers/sites.