We have a site which consists of 4 pages in this order of flow:
Default.aspx
List.aspx
SubmitForm.aspx
Thankyou.aspx
We use IIS URL Rewrite module to use a PURL for the landing (default) page. So this:
www.example.com/Chris123
is really this:
www.example.com/default.aspx?UID=Chris123
On the SubmitForm.aspx we have the submit button with a PostBackURL value which sends the form data to SalesForce.com's servers, captures the data, then redirects back to our Thankyou.aspx page.
Is the past, we haven't used the URL Rewrite module and the SalesForce submission has worked just fine. Now, however, with the URL Rewrite rules enabled, when the user clicks the button instead of going to the SalesForce server it redirects back to the form page, clears out the fields and fires all the form validation. This basically just causes a loop of form submit/redirect/form submit/redirect...
If I go into IIS and disable the User-Friendly URL rule (used only for the Default.aspx page) the form submits as expected to SalesForce. Turn it back on and the form submits to itself again.
I don't have a ton of experience with the URL Rewrite -- just basic User Friendly type scenarios. Any suggestions on where to poke around first would be appreciated.
We are running Windows Web Server 2008, app is .NET 4 web forms.
Ok, figured it out.
The issue ended up being that the WebResource.axd was getting caught by the URL Rewrite. Fixed it by adding this to the rule:
<!-- The following condition prevents rule from rewriting requests to .axd files -->
<add input="{URL}" negate="true" pattern="\.axd$" />
I'd read about that earlier but didn't think it was my issue since the PostBackURL was going off to another server. But I guess it makes sense since the PostBackURL needs the Javascript to redirect the post. rOnly reason I caught it was because my log file was capturing "WebResource.axd" as my PURL value with the form as the Referrer.
Here is the page where I found the actual code (at the end) which fixed my issue:
http://www.iis.net/learn/extensions/url-rewrite-module/url-rewriting-for-aspnet-web-forms
Related
In web application, in asp.net i am using one grid view, in that i have one link button, in row command event i am binding the url to that link, when i am clicking on that it is logging out, it is coming to login page. In row command i am writing the code like this
Response.Redirect(s, false);
where s containt the url like abc/abc_approval/xyz.aspx. it is giving particularly that url only remaing urls redirecting to their destinations.
when it comes to login page the url like this
Login.aspx?ReturnUrl=%2fabc%2fabc_Approval%2fxyz.aspx
help me please.
This does not seem the problem of redirect, you may have authentication failed on abc/abc_approval/xyz.aspx or any error could cause the redirect to login page. In web.config check the customErrors tag, Login page might be the default for unhandled errors. Put debugger on the suspected page to see if any error occurs.
After running a security scan across our web application (WebInspect), it has reported several XSS vulnerabilities with some aspx pages.
The request URL seems to be able to change the form action.
Example,
/Website/somepage.aspx/'+alert(1234)+'
the form action is changed to
action="'+alert(1234)+'"
To rule out our application code, I tried this with the default new Visual Studio webform project and it allows the same.
How can this be prevented?
I've always been told that un-validated input being reflected into the page is bad news.
just put something in the action, something like this:
<form id="id_form" runat="server" action="Default.aspx">
When the action form is not specified asp fills this attribute with which you wrote in the URL next to the last slash. If you write something there asp doesn't rewrite this.
Please check your global.asax - Application_Start to see if any routes have been defined.
Using: Visual Studio 2010 with ASP.net 4.0
I have a website which uses URL rewriting and I want to keep the rewritten URL on Postback. I've read a lot of the topics on this subject and I still haven't been able to figure out if this is possible.
For example:
http://localhost/ActualPage.aspx?PageID=4
Is rewritten as:
http://localhost/member/forum.aspx
The page contains a number of controls which use a Postback (for example a Telerik RadGrid with sorting and paging). Normally when the postback takes place the browser is redirected to the unrewritten url - the address bar shows /ActualPage.aspx?PageID=4 etc. In this scenario everything works correctly.
However I want to retain the rewritten URL after the postback, so I have coded to change the Form.Action property to be the rewritten URL like so:
Page.Form.Action = "/member/forum.aspx"
Now the page correctly retains the URL in the address bar but throws a "Validation of viewstate MAC failed" error when the postback occurs - which I would expect it too as the viewstate originated from a different URL.
Strangely this problem occurs even when enableViewStateMac is set to false (either in the page or in the web.config) - but I don't want to disable this anyway.
Effectively I think what I need to do is tell the page / viewstate mac authorisation that is it ok to accept input from this alternative URL but I can't find anyway of doing this. I've tried different URL rewrite system to see if that makes a difference, and i've tried added a generated machineKey - neither of which has made any difference. Is there any way of doing this?
In short I want:
Rewritten page with postback going to the rewritten URL
ViewStateMac enabled
No viewstate validation errors
I remember in earlier versions of .NET using a .browser file with FormRewriterControlAdapter but this doesn't seem to make any difference in .NET 4 (I don't remember if it successfully retained the URL anyway).
I have found a solution - it turns out the problem was actually unrelated and masking itself as a ViewStateMac issue.
Previously I had been redirecting all the URLs to one page, doing a database lookup and then using Server.Transfer() to deliver the correct page to the browser. The real problem was being caused by using Server.Transfer() - which it seems is recognised by Microsoft to be an issue when working with the viewstate.
I have made adjustments so IIS performs the database lookup, the entire rewrite and therefore Server.Transfer() is not used - and the original problem I had has been resolved.
OK. I'm having a ridiculous problem. I'm trying to use URL rewrite to redirection from www.domain.com to www.domain.com/default.aspx.
I thought by setting default.aspx as the default document it would automatically drop the user there. But for some reason it still comes up www.domain.com.
The reason I want it to go to www.domain.com/default.aspx is that the login control on the page doesn't seem to want to work when it is just the www.domain.com. But of course if I type in the www.domain.com/default.aspx then the login works fine. The login control doesnt seem to post at all if it is www.domain.com. Anyway, I'm trying to avoid troubleshooting why the login control is not firing and just force it to land on default.aspx anytime someone tries to go to www.domain.com. I'm using IIS7. Any ideas here?
You could add something like this to your Default.aspx code behind (in your Page_Load method):
if (Request.Url.LocalPath == "/")
{
Response.Redirect("~/Default.aspx");
}
Note that the default document setting normally allows that page to be displayed under www.domain.com/ and www.domain.com/default.aspx (it doesn't do any redirecting for you).
The anwer has to do with a breaking change in ASP.NET 4. Answer was that the form action was empty action="" when on extensionless root url. but if on that same page, but had the name of the page in the url (blahblah.com/default.aspx) the action gets filled in. the easy fix for me was to put Me.Form.Action = "Default.aspx" on the page load of the home page. problem fixed.
I've inherited an ASP.NET application that contains a login screen. When you first start up, or you haven't done anything for a while, it comes up. It turns out we don't need this extra layer of security, and I'm trying to remove it. I thought I removed the code that was doing the redirecting, but it's still going to the login page, even though I've told the app to use default.aspx as the start page, and ensured that default.aspx contains no code that should trigger the redirect (it's using a master page, but the master page also contains nothing that should be redirecting). Where else might it be redirecting to the login page?
Look for <authentication> sections (should be under <location> sections) in your web config and delete them
Sounds like it could be forms authentication in effect.
In the web.config file change the authentication mode value to none and see if that makes a difference.
<authentication mode="none" />
Found the problem. Even though I thought I had all the redirect code removed, there was still some buried in a user control on the default page. Removing that allowed me to bypass the login screen. So, I can't mark any of the responses as the answer, but I gave them all up votes as they were all good answers.