In asp.net (or vb) I must to call a page that only autenticates a user, returning the user data if the logon succed. This way, I would like to implement the sequence:
A blank page (mine) request the autenticator page (3rd part) automatically on load;
The user logs in the autenticator page;
My page reads the autenticator page results and do the actions.
I'm a very begginer in asp.net, and I'm using vb.net in the environment for coding the page "onload" event. I'm trying to use the "redirect('url')" method to call the autenticator's page, but in this way, obviously, I can't receive the result. How can I implement this sequence?
Problem solved. I discovered that when I call the autenticator server I must to inform a parameter with the URL for autenticator's page redirecting to (my page, in this case). This way, the autenticator's page itself will request my page after user login, then I'll be able to get the URL parameters with the user data. Thanks.
Related
Asp.net, when it sees an unauthenticated request, typically send the request to the login page.
An example is below:
http://localhost:9001/?a=x&b=y&c=z
Request to the login page:
http://localhost:9001/Account/Login.aspx?ReturnUrl=%2f%3fa%3dx%26b%3dy%26c%3dz&a=x&b=y&c=z
Notice how Asp.net creates a new parameter ReturnUrl but still retains the original parameters while redirecting to the login page.
I have a situation where the initial url length is around 1000+ characters and after this redirection, it becomes 2000+ which is kind of going beyond some browser limits.
Is there a quick way (configuration/httpmodule etc) to prevent the automatic parameters forwarding to the login page? (I can manage the login page needing these parameters to be extracted from ReturnUrl.)
For anyone who is wondering about this issue, the issue happens even in a default asp.net application but I was able to implement a fix for it.
Following is the fix:
Implement an HttpModule; handle the EndRequest event and check for 302/unauthenticated request
We have to use Response.RedirectLocation for most steps below
Using HttpUtility.ParseQueryString, get collection of all parameters
Using HttpUtility.ParseQueryString, get collection of all parameters within ReturnUrl value
Except ReturnUrl, strip out all other parameters which exist in ReturnUrl value
Update Response.RedirectLocation with ReturnUrl and remaining parameters (none in most cases), Url encoding as necessary
This will ensure the Url now has only ReturnUrl and other parameters which aren't copied in ReturnUrl.
You need to ensure that the login page (Account/Login in above e.g.) does not use any of these parameters or if they do, you have code to pull those out from value of ReturnUrl.
Hope this solution helps anyone with similar situation.
No duplicate of “Server.Transfer from ASP to ASP.Net” ;-)
On an IIS web server (running Classic ASP), I have a local URL that a user is remotely redirected to. Presumably, this call is made with data in the query string or transmitted through POST data. When this request is made, I need to remove this data (especially the query string) server-side, so none will be visible to the client.
For example, the user is led to http://example.com/dir/?data=payload. This is what requested, and this is what the user’s browser will display. Now I need the request resource to strip QueryString and Form data, so that the user ends up in e.g. http://example.com/dir/.
On MSDN, they have HttpServerUtility.Transfer, which adds a boolean to the classic Server.Transfer method allowing to preserve or clear data. However, when I try this in an aspx file transfering to an asp file, I get a 0x80004005 HTTP exception (“No http handler was found for request type 'GET'”).
Is it possible at all to “redirect” from an ASP.NET file to a Classic one?
Is there another, better way to remove request data server-side?
My options would be:
Use a redirect on the page without querystrings: Response.Redirect() This will clear post data as well.
Do a HTTP Request to scrape the HTML of the other page, and view it in your current page.
I would probably do option #1
Page Load, as a sentence of 2 words, means when the page is loaded, means, when all elements are loaded.
Let's say I have a page called Ask.aspx, and this page is only allowed to users who have signed in, so technically I would write something like this :
if(Session["id"]==null)
Response.Redirect("Login.aspx");
This mean, that I'm testing the Session AFTER the page loads, theoretically, I think it sounds wrong, now of course I won't notice it, it will be fast, I will try to access the page, then I'm redirected to Login.aspx, but... is it correct to test the Session on Page Load method?
The Page_Load is part of the page lifecycle. It is called when the Server loads the page, not when the Client loads the page...
So this is the correct place to check the Session Variable...
You're actually saying: Before I post the page back to the client, check if I have the ID property set for this session... If I don't - tell the client to redirect to the Login.aspx page...
This is the correct way of doing this...
I recommened you also read about Server.Transfer. The difference between it and Response.Redirect is that in Server.Transfer the server itself "redirects" to another page and outputs the result of the new page back to the client (without the client knowing about it).
If you are trying to limit access to specific pages, you would be better off using forms authentication.
http://support.microsoft.com/kb/301240
It is fairly easy to setup and it allows checking of credentials before the request is passed to the asp.net pipeline. In what you are doing, your page goes through the entire lifecycle (controls are rendred and bound to data, access to database, calls to web services etc.) before the request is rejected. Depending on your situation, this might be costly and will not scale well.
Edit: You can also hook in to the AcquireRequestState event in the global.asax. This will also spare the entire page life cycle.
Is it possible to rewrite URL on the fly, only when a part of the server code has already been processed for the "raw" URL and it becomes clear the parameters must not be revealed to the user? Like, I want to proccess all the GET parameters in my page code on the server and create a tracking record in the database, then serve the user the page but change URL to parameterless in the browser.
I guess all the web.config referred module techniques won't work as they offer URL rewriting before request is passed to the page code on the server. But it comes in my case that I receive an ugly URL from google adwords clicks and I do like it tracked 'as is' in my database, and I do certainly not like it show to user in her brower's bar.
At the same time I would like to keep URL unchanged without applying the URL rewrite most of the time unless some particular parameter shows up in it (like ref=adwords) so that any paramter written by hand or posted back would be displayed in the address bar.
Is it possible to do so by any means?
Have you considered writing an ActionFilter that would (if your controller or method is decorated with it) intersect your initial request, do all the necessary processiong and then redirect back to the requested page only indicating, that processing has been done?
This would be my first thought.
is there a way from a asp.net-page code behind with "Request.Redirect()" or another method to redirect to the last page (like Javascript history back)?
You can check the Request.UrlReferrer property, which will be set if the user has navigated to the given page from another one. This is nothing more than the HTTP Referrer header that a browser will set. This will be null if the user navigates to your page directly.
HTTP is stateless, so theres no way of being able to read the browsers history (on the server) in the same way that Javascript can (its client side).
However there are a couple of tricks you can use:
Javascript could write the URL into a textbox which gets submitted to the server
The last URL visited could be stored in session - which can be retreived on a later visit
If using the URL in session method, you'll probably want to code this into a HTTP handler (not module) and this will fire automatically on every request.
Obviously these will only work if the user has previously visited a page, and not directly.