I am kind of new to ASP.NET.
I wonder is there any way to restrict user can only enter from a specify page?
Like, I have a Page A to let them enter some information, then when submit, I will use Response.Redirect to Page B. But I don't want the user can go into Page B directly from URL....
If I use Session, then if the user didn't close the browser to end the session, the another user can just go into Page B directly...
Because the computer that access to these pages is using by the public, so I want to see if there is anyway to make sure they only do one way process? Can't go back to previous or jump to another page.
Thanks in Advance.
If you control the other page, start a session and set a session variable to a value that can be reversed that only your server could (or should) create, much like serial keys. For example 72150166 because the sum of every second number equals the sum of every other number (7 + 1 + 0 + 6 = 2 + 5 + 1 + 6) but you could choose an algorithm as complex or as simple as you want. When the user navigates to the second page, check the session variable. This is not invincible security, but it is better than checking the referrer (especially since some browsers do not set it) and I imagine security based on coming from a certain page doesn't have to be that strict.
Edit: You should also add it to a database and link it with the particular user's IP so someone else can't use the same key.
You can use Request.UrlReferrer property in the Page Load of PageB to see which page is the request coming from. If the request is not coming from PageA then redirect the user to PageA.
Check this link for more information: http://msdn.microsoft.com/en-us/library/system.web.httprequest.urlreferrer.aspx
Note: UrlReferrer is dependent on a request header and someone can set the header to mimic the request coming from PageA.
You could have the page that redirects send some sort of specifically generated hash/key in the query string that expires quickly and/or once viewed. This should be a lot more solid on the security side.
You will still need some way to store this key or value producing the hash so you can validate it on the receiving end- I would think your DB.
Related
When implementing the post-redirect-get pattern in a web application, it is common for the final step in your server code to look something like this (pseudocode):
if (postSuccessful)
{
redirect("/some-page?success=true")
}
That is, the redirect URL has some kind of success parameter in the query string so that you know when to display a nice looking "Your form has been submitted!" message on your page. The problem with this is that the success=true persists in the query string when it's only needed to initialize the page. If the user refreshes the page or bookmarks it, they will receive a false success message even though no additional POST has taken place.
Is there an elegant solution to this that doesn't involve using JavaScript to eliminate success=true from both the query string and the browser history? This solution works, but definitely adds complexity to a page's load process.
You can use server side technology to implement this feature, without any JavaScript. The stes are listed below:
When post is successful, redirect to /some-page with current timestamp information:
if (postSuccessful)
{
redirect("/some-page?success=true×tamp=1559859090747")
}
When server receives GET /some-page?success=true×tamp=1559859090747 request, compare the timestamp parameter with the current timestamp, check whether it is within the last 3 seconds (or you can change this number according to the network environment).
If the timestamp parameter is within last 3 seconds, then it means this GET /some-page?success=true request is a result of server redirect. If not, then it's more like a result of "user refreshes the page or bookmarks it".
In server code that handling GET /some-page, render different HTML according to the result of step 3. Display the success message only when current access is a result of server redirect.
I need to check where did the incoming request came from before loading a page
ex:
for user to view www.mysite/page1.aspx
request should come through www.othersite/page1.aspx
so on page1 load in mysite i need to check whether the request came from page1 in othersite.
i have tried Page.Request.UrlReferrer but i saw there some posts which tells every browser might not support Page.Request.UrlReferrer.
i can not pass visible parameters on URL.
This is a common issue when you do not want to allow request from arbitrary sites.
What you can do is, create a variable in session and put this variable in the Page1.aspx. When the page posts back, you should get that variable back and it should also match the one stored in the session. If it does not, you can be sure that the request is from some other server.
You can use PostBackUrl on the start page
And access your parameters with PreviousPage in the arrived page
if (this.PreviousPage != null)
{
var control = Page.PreviousPage.FindControl("..."); //Adjust your Id and add cast
}
Nota : This was also created to provide greater security redirection setting.
I have an aspx page, which is a "User Log-In" area. I want to pass the userid to another page which is linked from the aspx page.
the link I have looks something like this:
www.abcdefg.com/Home/Redirect/?authtkn=123456abcd=xxxx
I need the xxxx to be a session variable which in this case is userid.
**userid is not sensative information, this is simply to redirect the user to another page for specified information.
Any thoughts on how to pass a session variable to a URL, or if this can be done. The example www.abcdefg.com is a different domain (on a different server) from the original aspx page.
Why not appending like this?
string.Format("www.abcdefg.com/Home/Redirect/?authtkn=123456abcd={0}",
Session["UserId"]);
if i understood you correctly.
Think your question is how to maintain cross domain session or authentication.
Check this link Maintaining Session State Across Domains, may give you some idea
Or this one How can I share a session across multiple subdomains?
You don’t need to pass a session variable via the url. You can just start session on the next page and have access to all your session variables! If you do want the variables up there so you can quickly get to different userids with just a quick url change, send userid to the url on your previous page with with $_GET[ ].
I want find a platform/language agnostic solution to ensuring the origin of a FORM POST is from an expected source. I.e. Page1.aspx posting to Page2.php within the same web site.
Specifically what I am attempting to do here is to prevent request forgery.
Use a hidden field in your form, which contains a token your app generated. Store the token in the user session. When the form is submitted, your app will check that the value of the hidden field is identical to the value stored in the user session.
If it is identical, then you know the submitted form comes from where it is expected to come.
Old Thread, but might still be useful.
If you do not have session info set (best option) then you can include a hidden field with an encrypted timestamp then compare it (after de-crypt) to the current time on the process end to make sure it is relatively close and thus as recent as you deem necessary.
You could include into the form a hidden field which would be the SHA1Hash("some-secret" + Remote_IP + PerSessionSecret).
The PerSessionSecret is something you autogenerate in the beginning of the session. "some-secret" is a global secret value - which will help a little bit in case the randomly generated PerSessionSecret turns out not to be very random enough.
Then do the same calculation upon the form submission and you know it's most probably submitted from the same client that it was sent to. (Of course, if you have multiple clients behind the single address, like a proxy or a NAT, you can not distinguish between them reliably).
i need to check whether the user clicking the browser Refresh button and redirect to error page. Can we do this in javascript or any server side methods in ASP.net
If you give each link you present a unique ID (e.g. a GUID) in the URL as a parameter, then you can keep track of all the requests you've processed. (You could clear out "old" requests if you don't mind the mechanism not working if someone leaves a browser open for a few days and then hitting refresh.) The first time you see a GUID, write it into the table. If you see it again, redirect to an error page.
It's pretty ugly though, and users could just edit the URL to change the GUID slightly. (You could fix this last flaw by recording the GUID when you generate it, and update the table to indicate when it's been used.)
In general, users expect to be able to refresh the page though - particularly for GET requests (even though most users wouldn't know what that means). Why do you want to do this?
Well, you can use a very famous tecnique called "Syncronizing Token" or something like that =D, mostly used to send forms.
This will work like this:
Create a function to provide a pseudo-random string token.
For every request to you page, check if a variable in Session, ex: Session["synctoken"] if present. If no, then it is the first time, generate a token and store it there.
Every link request, ex: "mypage.aspx" put a get called synctoken with another token, diferent from the one you have stored in the Session, it goes like "mypage.aspx?synctoken=2iO02-3S23d".
Then, comming back to (2), in a request, if a token is present in Session check if the GET is present (Request.QueryString["synctoken"] != null). If no, send Error. If yes check whether the Tokens (Session and GET) are different. If they are different, it is ok, store the GET into your Session (Session["synctoken"] = Request.QueryString["synctoken"]) and go to step (2). If no, then the user refreshed the page, there goes your error.
It goes like:
if (Session["synctoken"] != null) {
if (Request.QueryString["synctoken"] != null) {
if (Request.QueryString["synctoken"].ToString().Equals(Session["synctoken"].ToString())) {
// Refresh! Goto Error!
MyUtil.GotoError();
}
else {
// It is ok, store the token and go on!
Session["synctoken"] = Request.QueryString["synctoken"];
}
}
else {
MyUtil.GotoErrorPage();
}
}
else {
Session["synctoken"] = MyUtil.GenerateToken();
}
Sorry if I could not be more clear.. good luck!
You can do that, but I'm sure you shouldn't. The user is in control of the browser, and if she feels like refreshing, it your job to make sure the page refreshes. Returning an error page is the wrong answer.
you can use client side hidden variable to store a counter or you can put counter in session. Well I would suggest you to expire the page on refresh there are ways you can achieve this disable cache etc [like all banks website do].