I am working on a c# .NET website in which the user can click on a link and get redirected to another web page in a separate website also owned by us. The code is very easy to understand, there is a switch followed by a call to Response.Redirect(the_url_we_want_to_go_to).
I have debugged it numerous times and I can confirm that when the debugger hits this redirect line that the parameter is correct. It points to the QA version of this other website. qa.samplesite.com lets say. However, the browser does not go there. The browser instead hits the test environment instead. Lets call it test.samplesite.com. This is the problem.
I understand there are a million things in between the app servers these two separate websites are on, but maybe one of you has seen something like this before. More specifically, is there a way to catch outbound traffic in the debugger or is there a way to see outbound traffic on the app server itself (in IIS)? I am familiar with intercepting inbound traffic inside of httpmodules. Maybe this isnt a stackoverflow question...
Thanks for your help!
Use the very nice HTTP sniffer "Fiddler". It will allow you to see all HTTP requests. You should verfiy that a) the redirect target is correct (it might be overwritten later in the request pipeline. A Response.Redirect is not the final word) and b) that you don't have a second redirect after the first one.
You can try using the overload of Response.Redirect as
Response.Redirect("url_here", true);
This will stop the response on current page (as endResponse is set to true) and redirect to the url.
If you still have the issue, then this might be some name resolution error.
Check to see you your hosts files in the windows directory found here
C:\Windows\System32\drivers\etc\hosts
Hope this will do it.
I finally figured a similar issue I had. It was quite silly. I had copied some .aspx pages making minor changes. The page where I tried to redirect the client, had it's "CodeBehind" setting wrong. So it redirected to the right page, but loaded the CodeBehind from another page!
Related
Hy all!
I'm developing a MVC 4.0 web application with C# and came accros the following error.
In major browsers (Chrome, Mozilla Safari, etc...) when i click logout in my web application it does the correct, logout the current user.
When i do the same operation on IE, dosen't work, i login with the new user, and IE keeps the last user until i press ctrl+F5.
The only thing i'm using for authentication is Sessions, nothing more.
Someone came acrros this issue? i've tried clear cache, clear sessions with abadon, clear, removeall and nothing seems to work when i'm on IE.
If you guys need some more info to help me with that, i'll answer as soon as possible!!
I've found the following works:
Session.Clear()
Session.Abandon()
Session.RemoveAll()
If Request.Cookies("ASP.NET_SessionId") IsNot Nothing Then
Response.Cookies("ASP.NET_SessionId").Value = ""
Response.Cookies("ASP.NET_SessionId").Expires = DateTime.Now.AddMonths(-20)
End If
Usually, browsers implement it so that ctrl+f5 means "make an http request for the current url, without the browser cache). So, no matter what you do after the fact in your server-side code, because IE is by default reloading the current page from its local memory without even hitting your server, you will not appear logged out. Then, when it does eventually go back to your server, it's still sending the same cookie because the page that would have logged you out is never actually hit.
One way to test if this is happening, is to set a breakpoint in your logout code. Refresh the page without holding ctrl in IE, and see if the breakpoint is even hit. If it's not, then you know client-side caching is the cause.
Workarounds:
This code on the server will send the page with metadata indicating the browser is not allowed, under any circumstances, to cache the page on their side:
response.Cache.SetAllowResponseInBrowserHistory(false);
response.Cache.SetCacheability(HttpCacheability.NoCache);
response.Cache.SetNoStore();
response.Cache.SetExpires(DateTime.Now);
response.Cache.SetValidUntilExpires(true);
-- or --
When you go to your logout page with a link like this: /logout or /home?logout=1 add an extra paramter like this: /logout?cacheBust=123yt74y5t, making the last part random. This works because most browser caches will cache based on url, so if you randomly mess up an unimportant part of the url, you can get around it. One advantage to this method is that you actually want the browser to cache some pages, but not others, and this is a more client-side way of determining if you want a fresh copy from the server or not.
Previously, when I tried to do an ajax call to an ashx as a non-superuser account (i.e. as portal specific user) my web server would return cookies to clear my authorization. I posted a question about this and it seemed the answer was to make sure that the portalid=xx was specified in my GET parameters.
However, I have just found out that if I add portalid=xx in a POST request, DotNetNuke seems to ignore and and log out any non-superuser account.
How can I keep authorization during DNN POST ajax requests?
I think I have a good handle on the whole situation, and unfortunately it appears that the only true solution is to make sure each child portal has its own subdomain rather than a sub-url (e.g. portal.domain.com rather than domain.com/portal).
The problem is that when your portal 0 is domain.com but portal 1 is domain.com/portal everything works correctly until you need to access an .ashx file via ajax. What happens then is the URL that's requested is instead domain.com/DesktopModules/MyModule/Handler.ashx, which does not contain the /portal/ in it, thus causing DNN to think you are doing a request on portal 0 and logging you out.
While GET requests can overcome this with a portal=1 parameter, this does not seem to work for POST requests.
Therefore, the best solution it seems is to have your portal on a distinct subdomain (portal.domain.com), and then you don't risk missing something like this.
I've found a few things for you to check out and see if any of them solve your problem.
Make sure you are using a ScriptManagerProxy. This allows ascx pages to use AJAX while the parent page is also using AJAX.
There have been many reports of people not being able to run AJAX with DNN if Page State Persistence is set to "Memory". Those who experience this have been able to fix it by switching Page State Persistence to "Page". The easiest way to do this is to run this query:
update HostSettings
set SettingValue='P'
where SettingName='PageStatePersister'
After you run that, you'll need to recycle the application. If you don't have access to the server, just add a space or carriage return to your web.config file (that will force the app to recycle).
Lastly, you might see if you have this line in your web.config. Sometimes removing it will help:
<system.web>
<xhtmlConformance mode="Legacy" />
</system.web>
I have been working on a legacy project (although C#) and trying to solve a session problem that have been encovered for years. It hapens on IE8 and prior versions. On IE9, Google Chrome, Firefox and Safari works fine.
In other words, we have a management software that works fine on all browsers. But there is a specific page that makes tons of Ajax requests, and in some point it loses the session data.
I have checked for cookie problems with Fiddle but they are always sent and the same.
These clues make us think that the problem is within the application. But if we remember the problem occurs just in IE8 and prior versions we think the issue is probably in the browsers.
We also use a legacy Ajax library. And the problem mustn't be there as many of our aplications
use it and they doesn't have the same problem.
We are using IIS7 with State Server
I'm almost out of ideas. I hope you have some.
I got it!
Using Fiddler, I saw a very suspect request for "/". There was something requesting for the site base URL. And I remembered that the default page of this particular web application kills the session data, in other words calling the login page also means to log the user off.
After some hours of debugging and sniffing I found what was making such request.
There is a javascript function that creates some image tags. Some times those tag were created with an empty address, in other words the src property of the img tag was a string with 0 legth.
It must be an IE8 and older versions bug, as they request the website root instead of not requesting anything. Maybe it's not a bug, but this behavior is certainly unexpected.
Phew! I still can't believe I found it.
Losing session state can be result of the application error. But if you claim that this happens only on IE8 and older versions, this could not be the case...
So I would suggest you to use page ViewState instead of session state. Let me know if did the trick for you?
Here is sample how to create propety based on page viewstate, just make sure you have enabled viewstate on page level:
public string MyProperty
{
get
{
return ViewState["MyProperty"] as string;
}
set
{
ViewState["MyProperty"] = value;
}
}
Two aspx pages are involved with the problem. in one form I am collecting the entity and binding it in a session variable and then with button clicked, I am trying to get to the other aspx page with response.redirect("") method. But, the problem is its gives me an error message with a strange URl.
let me show you the code I have writen
formSaleMoneyReceiptEntity = ViewFormSaleMoneyReceipt_DAO.GetMoneyReceiptByFormSL(formSl);
Session["MoneyReceipt"] = formSaleMoneyReceiptEntity;
Response.Redirect("~/Reports/MoneyRepeiptFormReport.aspx",false);
I am using local host and the URl I am getting is that
http://www.google-feed.net/results.php?q=localhost 5808 StudentManagement FormSaleMoneyReceipt aspx &cx=002904446094441487865%3Ate-nlsbrcdy&cof=FORID%3A10&ie=UTF-8&said=&do=search&empty=0&from=2&CID=1
why is this so? I don't have any idea. Please help me out.
It looks like the URL that is passed to the browser doesn't exist, so you're getting a redirect to a Google search page instead.
Is it ~/Reports/MoneyReceiptFormReport.aspx by any chance?
A good tool to use to debug this kind of situation is Fiddler. This sits as a proxy between your Web server and your browser and issues a trace of what requests and responses are made. Browsers have a habit of reformatting error messages, Fiddler will show you exactly what's sent to the server and what comes back.
I use Process.Start("firefox.exe", "http://localhost/page.aspx");
And how i can know page fails or no?
OR
How to know via HttpWebRequest, HttpWebResponse page fails or not?
When i use
HttpWebRequest myReq = (HttpWebRequest)WebRequest.Create("somepage.aspx");
HttpWebResponse loWebResponse = (HttpWebResponse)myReq.GetResponse();
Console.Write("{0},{1}",loWebResponse.StatusCode, loWebResponse.StatusDescription);
how can I return error details?
Not need additional plugins and frameworks. I want to choose this problem only by .net
Any Idea please
Use Watin to automate firefox instead of Process.Start. Its a browser automation framework that will let you monitor what is happening properly.
http://watin.sourceforge.net/
edit: see also Google Webdriver http://google-opensource.blogspot.com/2009/05/introducing-webdriver.html
If you are spawning a child-process, it is quite hard and you'd probably need to use each browser's specific API (it won't be the same between FF and IE, for example).
It doesn't help that in many cases the exe detects an existing instance and forwards the request there (so you can't trust the exit-code, since the page hasn't even been requested in the right exe yet).
Personally, I try to avoid assuming any particular browser for this scenario; just launch the url:
Process.Start("http://somesite.com");
This will use the user's default browser. You have to hope it appears though - you can't (reliably and robustly) check that externally without lots of work.
One other option is to read the data yourself (WebClient.Download*) - but this may have issues with complex cookies, login, user-agent awareness, etc.
Use HttpWebRequest class or WebClient class to check this. I don't think Process.Start will return something if the URL not exists.
Don't start the page in this form. Instead, create a local http://localhost:<port>/wrapper.html which loads http://localhost/page.aspx and then either http://localhost:<port>/pass.html or http://localhost:<port>/fail.html. localhost: is a trivial HTTP server interface implemented by your app.
The idea is that Javascript gives you an API inside the browser, which is far more standard than the APIs on the outside of browsers. Since the Javascript on wrapper.html comes from the same server and even port as the subsequent resources, this should satisfy the same-origin policies in current browsers.