Example: url is http://www.mydoman.com/test.aspx/88
I click an asp:Button which cause a postback, but now the url comes up:
www.mydoman.com/test.aspx/test.aspx
There is nothing special in the button, just id and runat.
This only happens when I start with the "/88" in the starting url?
Why, and how can I prevent the duplication. After the postback I want the url to be the same as when started.
We probably need more detail to help here.
For example: What is the definition of your form, and do you use any sort of routing?
I don't believe http://www.mydoman.com/test.aspx/88 is valid syntax though, shouldn't it be
http://www.mydoman.com/88 or http://www.mydoman.com/test.aspx?ID=88 ?
Related
Is there a trusted way to disable the direct access to an special web page? I mean I want to open it only by clicking on a Button for example. I know I can access to the webpage by using this code but It can not prevent accessing to the web page directly (Pasting the url or typing it):
Response.Redirect("~/Code.aspx")
Thanks
This is a long shot because I don't have the time to test this now (I can see some downvotes coming already!), but...
In the "Code.aspx" page, check for Session["allowed"]. If the value is not there, end the response.
Next, make another page (from where Code.aspx can be accessed). In this page, set Session["allowed"] and then do a Server.Transfer() to Code.aspx, which will then run OK.
Finally, at the end of processing Code.aspx., remember to clear the Session["allowed"] variable again.
Hope this makes even vague sense :)
You may be able to write a piece of code on page load that checks the contents of HttpContext.Current.Request.ServerVariables("HTTP_REFERER") - if it's blank, a user has navigated to the page directly and you can handle it that way.
On the source page create a token into a hiddenfield. To your button add PostBackUrl property and let it point to your destination page.
On the destination page you can validate that the request was made from your allowed source page. And you dont need to use session and all its drawback.
Check this Link for detailed information about how to use the mentioned property.
I've recently been hacking with webforms seeing if it's possible to use one of my (routing) projects with it. So far, it's been nothing but trouble, but I'm almost to the point that it "works"
I made a page "Test.aspx". At Global.asax, I made it so that it's served at /test instead of /Test.aspx. This works completely. It descends from a custom page class of mine. The custom class finds HtmlForms in the page and rewrites their Action attribute with the proper value: /test.
Now I hit the great brick wall titled Viewstate and ASP.Net events. I added a button to Test.aspx with an OnClick handler. I can click the button, and the page will postback and such, but the OnClick event will not occur. I'm not understanding how a simple URL change can break viewstate like this, as I was not under the impression that Viewstate would track such a thing. Also, IsPostback will be false, even though HttpMethod==true. This is not making any sense to me.
Also, I've disabled EventValidation because I figured that'd be trouble, but this problem persists.
How can I make viewstate and postbacks work as usual when rewriting URLs?
(Note, my form of URL rewriting does all rewriting internally, there is never a HTTP redirect sent to the user)
You might need to tell the HttpContext that the URL is being rewritten as well.
Try doing something like this:
HttpContext.Current.RewritePath("/test");
The IsPostBack is used for check whether the request is from the control of the page itself.
And the HttpMethod is used for check the request type.
I thought you couldn't change the QueryString on the server without a redirect.
But this code works* for me:
Request.QueryString edit
I'm so amazed.
So here are my questions regarding this:
Why is Request.QueryString readonly?
Why does this code/hack work*?
How safe is it, if you change to readonly as soon as you are done editing, both regarding bad errors or unexpected behaviour, and regarding maintaining and understanding the code?
Where in the event cycle would it make most sense to do this crazy edit if you are only using PageLoad and OnPageRender?
*More details:
I have a page with items that are grouped into tabs. Each tab is an asp:LinkButton
I want to be able to link directly to a specific tab. I do that with a QueryString parameter 'tab=tabName'. It works. But when I then click a new tab, the querystring is still in the Url, and thus the tab specified in the Querystring gets activated and not the one I clicked.
By using Request.QueryString edit this does not happen. Then my solution 'works'.
Thanks in advance.
Well the QueryString property is readonly because it cannot be changed on a single request. Obviously the browser sends only one request with only one string so only one collection is created. The hack uses reflection (i.e. manipulates the code and the memory) to change stuff that you cannot change normally. This hack breaks the encapsulation and the design of the QueryString property. You should not use it. It makes no sense from design standpoint. Your query DOES NOT change so why change the object that represents it? Only the browser can send new query string so you are basically lying to your own code about what the browser sent.
If you want the tabs to use the URL just use Hyperlinks instead of LinkButton.
From what I remember reading, this is a security standard that all browsers adhere to. It's main purpose is to stop phishing attacks, where someone could have the website www.MyLameWarcraftPhishingSite.com" and when someone hits the page, rewrite the url to look like www.blizzard.com. The only way to get to that url is to actually redirect to it.
mmm, last post was in Feb 11 - hope its ok to post in this.
I have an have an ASP.Net page which contains a button. This Page contains a ServerSide Paypal button.
When pushed my server does various clever things on the back end and then rewrites the response as a form and some javascript which posts this form to paypal..
This all works great.
However, if the user then elects to click back, they will arrive at my generated self-posting form and that will forward them again to Paypal.
I thought if I could find a way to have my generated form page not exist in the history, then this will solve my problem. but I have no idea how to correct this.
How can I remove my page from the history or just have it never appear?
Update: Thanks to all... Those are some great answers. Upvoted all good ones but went with splattne on account of clever use of hidden field rather than cookies for basis of decision.
window.location.replace(URL);
window.location:
replace(url)
Replace the current document with the
one at the provided URL. The
difference from the assign() method is
that after using replace() the current
page will not be saved in session
history, meaning the user won't be
able to use the Back button to
navigate to it.
I'm not sure if that can be done. But here is an idea how you could prevent that resubmit of the form.
You could insert a hidden input in your form which at the beginning would be empty. On submit you'll write a value in that field and make sure you check on every submit attempt if this field is empty.
If it is not empty on submit you know that the form was previously sent and you could warn the user.
As a web application, you'll never have full control of the user's browser. Even if there was a way to instruct the browser to not store the page in history, which I doubt, you can't be sure it'll work. For example, a clever user could tweak an open-source browser to store every page in history, no matter what.
I think you should try to approach the problem from another angle. You could, for example, detect that it's the same form which is being forwarded and not send it to paypal the second time. The important thing is to do it server-side.
Perhaps you could set a cookie before submitting the form.
When the page is loaded, check for the existence of that cookie (meaning the form was already submitted). If found, instead of automatically submitting the form, automatically go back (window.history.back()) again.
I'm not sure if you can do this easily with PayPal integration, but the
"Post / Redirect / Get" pattern can be used to address this problem
A useful Hint for some might be this...
window.history.go(-2);
particularly in the advent of a load failure warning popup.
You could simply programme your page not to submit, or to do something / navigate somewhere else, if window.referer is the Paypal page you are trying to avoid invoking a second time.
protected void Page_Load(object sender, EventArgs e)
{
Page.RegisterClientScriptBlock("", "<script>if(history.length>0)history.go(+1);</script>");
}
In ASP.net Webforms how do you detect which Textbox someone pressed enter?
Please no Javascript answers.
I need to handle it all in the code behind using VB.NET.
Why do you need to determine the which TextBox was pressed? Are you looking to see which TextBox was being focused so that you can trigger the proper button click event?
If you are looking to do something like this, one trick I've done was to "group" the appropriate form elements within their own panel and then set the "DefaultButton" property accordingly.
Doing this allows me to have a "Search by Name", "Search by Department", "Search by Id", etc. Textbox/Button combination on a single form and still allow the user to type their query parameter, hit Enter, and have the proper search method get invoked in the code behind.
I suspect it cannot be done without javascript - when you hit enter, the browser submits the form - it doesn't submit what field had the focus. So unless you use JS to add that information to the form being submitted, you're out of luck.
Without using Javascript, you just can't. That information is not conveyed from the client browser to the server.
As far as I know there is no possible way for a server side script to detect that. It simply does not get sent to the server. It must be done client-side (i.e. With Javascript) and then sent to the server.
I solved this for one site's search by looking at the Request.Form object, server side to see if the search box had a value. I did it in a base class that all my pages (or a base class for the masterpage) inherit from. If it has a value, the odds are pretty good somebody typed something in and hit enter and so I handled the search.
In the event handler, the "source" object (the first parameter of the event handler) is the object raising the event. Type it to button and get the name, or use reflection to get information out of the non-typed object.
In addition, if the control is a child of a web control that you do not have raise its own events (just saying...) then you can use OnBubbleEvent to determine what's going on. OnBubbleEvent also has a "source" parameter you can type, or use reflection on.