I encountered this using Fiddler, e.g.:
Request sent 57 bytes of Cookie data: killmenothing;
ASP.NET_SessionId=3vufx3vqzzlm4q55xhoej4go
Could someone please explain me the exact meaning?
UPDATE:
I finally managed to find the source: it's a way to make sure a cookie exists by setting one, just as described quite a bit of time ago in this article.
Thanks for your contributions that helped me to address my search in the right direction.
This is not a built in feature.
Looks like a way for the website developer to eradicate certain cookie data by replacing it with that string.
Check your web config. Its possible its the cookie name used for authentication.
Related
I am writing a http proxy and I need to test if it can handle POST requests, but I can not find a URL that uses POST method.
Could someone give me one?
Thanks.
Try this one: http://ptsv2.com/
Read the instructions on the page. To help you further, I suggest that you use Postman, (it doesn't answer requests but is a great tool to help you compose your requests)
Also you need to show that you've done some research first. Or your question will get downvoted to hell.
I saw this question in another post but the solution did not work correctly.
I use:
System.Net.Dns.GetHostEntry(HttpContext.Current.Request.ServerVariables.Item("REMOTE_HOST")).HostName
This worked correctly on localhost but on server it has problems and returns an empty string.
Any idea?
Two things to consider:
Take into account that HttpContext.Current.Request.ServerVariables.Item("REMOTE_HOST") will return the name of the host making the request, not the address.
Try doing System.Net.Dns.GetHostByAddress(Request.ServerVariables.Item("REMOTE_HOST")).HostName instead.
You can find a list of the Server Variables at Microsoft's MSDN website.
Hope that helps,
To get client IP address use
HttpContext.Current.Request.UserHostAddress.ToString
or
HttpContext.Current.Request.UserHostName
To get client browser use
HttpContext.Current.Request.Browser.Browser
I find out that already in VS2010 "GetHostByAddress" is deprecated.
Instead, use: System.Net.Dns.GetHostEntry(HttpContext.Current.Request.ServerVariables["REMOTE_HOST"])
A page we have is visited by users from two domains. lets call them x.com and y.com
I want some of the code to only display when the user visits from y.com- how do i do this in the same vbscript file? Or do i HAVE to have separate files?
i was thinking something like
if request.SOMETHING.contains("x") then etc
Try Request.ServerVariables("HTTP_REFERER").
You'll notice that REFERER is misspelled; that's because HTTP_REFERER was set in stone in RFC 1945 before anyone caught the spelling error.
More info
In addition to checking the referer as others have suggested you could also while calling the page put a value in the url indicating where you have come from (assuming you have access to the pages you are linking from).
This is more easy for a malicious or just curious user to mess with than the http referrer so in some ways it is less reliable. However you should bear in mind that the http referrer isn't a guaranteed solution anyway (a browser might not send it, security programs might strip out the header, etc.) and that any user who manually edits things in the querystring that they shouldn't be playing with has no grounds for complaint if things stop working. As long as it won't be a security hole it should be fine. And if changing the value is a security hole you shouldn't use the referrer either since that can be easily modified by those with a mind to.
request.servervariables("HTTP_REFERER")
I'm trying to set a session cookie restricted to a particular path (let's say /foo) when a user logs in. The complication being that the login page is on /, but the request immediately redirects to /foo/something. Something like this:
Request:
POST / HTTP/1.1
username=foo&password=bar
Response:
HTTP/1.0 302 Found
Location: http://example.com/foo/home
Set-Cookie: session=whatever; path=/foo
However, the relevant bits of the RFCs I could find (rfc2109 and rfc2965) say this:
To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if any of the
following is true:
The value for the Path attribute is not a prefix of the request-
URI.
...
The cookie-setting process described above seems to work okay, but as far as I can tell the RFCs are saying it shouldn't.
I'd like to use this in a production system, but I really don't want to do that if I'm going to face horrible browser incompatibility problems later.
Am I misreading the RFCs?
Thanks in advance!
Don't pay any attention to those RFCs; they diverge from reality pretty badly.
There's currently an IETF WG that's documenting actual cookie behaviour; their document, while just a draft, is much better source material.
See:
http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/
If you don't find text that addresses your question in the draft, bring it up with the Working Group!
Based on your question, I think your understanding of the RFC is correct. It sounds like you want to set the cookie after the redirect to '/foo/home'. I think the real question is: "How do you tell '/foo/home' that the user was authenticated correctly by '/'?"
If you must use a Location header (redirect) to get from '/' to '/foo/home', it seems the only way to do this would be to use a query string parameter in the Location header's value.
Maybe a design question to consider is: why are users authenticating against a URL outside of the path they will be accessing securely? If the only secure content is under '/foo', then why not POST to '/foo/login' instead of '/' for authentication?
This problem has been solved thanks to your suggestions. See the bottom for details. Thanks very much for your help!
Our ASP.NET website is accessed from several specific and highly secure international locations. It has been operating fine, but we have added another client location which is exhibiting very strange behaviour.
In particular, when the user enters search criteria and clicks the search button the result list returns empty. It doesn't even show the '0 results returned' text, so it is as if the Repeater control did not bind at all. Similar behaviour appears in some, but not all, other parts of the site. The user is able to log in to the site fine and their profile information is displayed.
I have logged in to the site locally using exactly the same credentials as them and the site works well from here. We have gone through the steps carefully so I am confident it is not a user issue.
I bind the search results in the Page_Load of the search results page the first time it is loaded (the criteria is in the query string). i.e.
if (!IsPostBack) {
BindResults();
}
I can replicate exactly the same behaviour locally by commenting out the BindResults() method call.
Does anybody know how the value of IsPostBack is calculated? Is it possible that their highly-secure firewall setup would cause IsPostBack to always return true, even when it is a redirect from another page? That could be a red herring as the problem might be elsewhere. It does exactly replicate the result though.
I have no access to the site, so troubleshooting is restricted to giving them instructions and asking for them to tell me the result.
Thanks for your time!
Appended info: Client is behind a Microsoft ISA 2006 firewall running default rules. The site has been added to the Internet Explorer trusted sites list and tried in FireFox and Google Chrome, all with the same result.
SOLUTION: The winner for me was the suggestion to use Fiddler. What an excellent tool that no web developer should be without. Using this I was able to strip various headers from the request until I reproduced the problem. There were actually two factors that caused this bug, as is so often the case with such confusing issues.
Factor one – Where possible the web application uses GZIP compression as supported by all major browsers. The firewall was stripping off the header that specifies GZIP decompression support (Accept-Encoding: gzip, deflate).
Factor two – A bug in my code meant that some processing was bypassed when the content was being sent uncompressed. This problem was not noticed before because the application is used by a limited audience, all of which supported GZIP decompression.
If they're at all tech-savvy, I would have them download Fiddler or something similar, capture the entire HTTP session, and then send you the saved session. Maybe something in there will stick out.
Meanwhile, see if you can get an install of ISA Server (an evaluation install, if you have to, or one from MSDN if you have or know anyone with a sub) and see if you can replicate it locally.
Is it possible the client has disabled Javascript and it's not picking up the _EVENTTARGET form value?
It might be some sort of proxy which creates a GET request out of a given POST request...
I am not sure how the IsPostBack is calculated, but my guess would be that it checks the HTTP request to see if it's a POST or a GET...
Ohh, yeah. It's definitely NOT "_EVENTTARGET" BTW...
I know this since Ra-Ajax does NOT pass any of those parameters to the server and they (Ra-ajax requests) are processed as IsPostBack requests...
Location, location, location. Check the user's culture. Normally that causes issues.
Could you create a test Post Page that passes the same things that your search page does, and in the Page_Load write back all of the post to make sure they are getting passed, particularly the __VIEWSTATE.
foreach (string key in Request.Form)
{
Response.Write("<br>" + key + "=" + Request.Form[key]);
}
Then ask one of the users to forward back what they see on that test page.
EDIT: There is documentation that some firewalls can corrupt the VIEWSTATE and some methods to get around it: View State Overview
Check the IIS logs to see if the request even makes it to your server. The ISA setup might be caching the initial request and serving that up in the succeeding requests.