Ways to avoid user from accessing page with querystring - c#

I have a page that I want it to be accessed when the user finishes saving the form. I have a Response.Redirect("MyPage.aspx?queryStringParam=123") (the value chages, based on field selection) .
On the page I have a check to see if the value is being passed and everything is working:
if (Request.QueryString["queryStringParam"] != null)
{
int queryStringParam;
if(int.TryParse(Request.QueryString["queryStringParam"], out id))
{
hfQueryStringParam.Value = queryStringParam.ToString();
}
else
{
Response.Redirect(ResolveUrl("~/Default.aspx"));
}
}
else
{
Response.Redirect(ResolveUrl("~/Default.aspx"));
}
If the user tryes to type the page, it checks for the queryString and if it's not being passed, it will redirect him to the default page, but hte problem is, if he types the queryStringParam into the url, the page will load. I don't want that to happen.
Is there any way to block the user from accessing the page by typing the url and only access it with Response.Redirect?

From the page where you are saving the form,store something in the session just before the redirection to MyPage.aspx. In the MyPage.aspx first check for the session value. If it does not have a value which you set from the previous page, redirect the user to the default page.

Related

How to detect response.redirect? (Comparing to postback)

i have a question. Often, we use if else for postback in asp.net - for example:
if (!IsPostback) {}
else {}
Comparing postback to response.redirect, is there any keyword i can use to represent response.redirect in the same fashion inside my page load?
If you do a Response.Redirect, by definition the next page load will not be a postback. If you want to detect, on page load, whether or not the user was Response.Redirect'ed to that page, use a querystring parameter.
Redirecting page:
if (shouldRedirect)
{
Response.Redirect("http://mysite.cool.site/stuff/awesome/webapp/display.aspx?IsRedirect=1");
}
Receiving page:
if (Request.QueryString["IsRedirect"]=="1")
{
Do whatever you need to do to account for the fact that you were redirected here.
}

How Postback is detected on serverside of a webform

I wonder how postback is detected on serverside?
Generally, the state of controls on a page are stored in Viewstate and they traverse back and forth on every postback to the server.
Since http is stateless, how will the server differentiate between a postbacked page and Initial Page load.
we can use Page.IsPostback property which is auto set to true or false for postback and initial load respectively. But my question is what controls this assignment of true and false to Page.Ispostback property and how server figure out a form postback?
Is there any hidden field that server uses to detect a postback of a Page?
In the context of ASP.NET, first page load is a HTTP GET request, after that they are POST requests.
Similar question here.
Technically, first page could be made as a POST, but this is not typical.
It's somewhat complicated. System.Web.UI.Page weighs in at roughly 6500 lines with numerous public/internal dependencies.
http://referencesource.microsoft.com/#System.Web/UI/Page.cs
From your earlier comment:
just like we expected, client sends some hiddenfields to server to
detect the postback and based on this the IsPostback is set to true.
You are correct that hidden fields are used. IrishChieftain was also correct in pointing out that the HTTP verb is used in the determination.
The overall process is stateless.
Page proceeds through a number of steps to make the determination.
Starting with ProcessRequestMain():
Check if the page uses a PageAdapter.
Call the PageAdapter's DeterminePostBackMode() method, or call DeterminePostBackMode() on the page itself.
...which calls GetCollectionBasedOnMethod()
Is the request a POST? try to return the Request.Form collection.
Do we get a collection from GetCollectionBasedOnMethod()? if so check for certain hidden fields.
Check for a cross-page postback, and set _pageFlags[isCrossPagePostRequest] accordingly.
Those appear to be the prerequisites necessary to call IsPostBack.
public bool IsPostBack {
get {
if (_requestValueCollection == null)
return false;
// Treat it as postback if the page is created thru cross page postback.
if (_isCrossPagePostBack)
return true;
// Don't treat it as a postback if the page is posted from cross page
if (_pageFlags[isCrossPagePostRequest])
return false;
// Don't treat it as a postback if a view state MAC check failed and we
// simply ate the exception.
if (ViewStateMacValidationErrorWasSuppressed)
return false;
// If we're in a Transfer/Execute, never treat as postback (ASURT 121000)
// Unless we are being transfered back to the original page, in which case
// it is ok to treat it as a postback (VSWhidbey 117747)
// Note that Context.Handler could be null (VSWhidbey 159775)
if (Context.ServerExecuteDepth > 0 &&
(Context.Handler == null || GetType() != Context.Handler.GetType())) {
return false;
}
// If the page control layout has changed, pretend that we are in
// a non-postback situation.
return !_fPageLayoutChanged;
}
}
System.Web.UI.Page class uses various methods to check whether the current request is a post back (setting the IsPostBack property). Some (not all) of these are:
Check whether the current request is a cross page post back, ie, whether it is a post request to the current page from another page. If so the request is treated as a post back.
There is a __VIEWSTATEGENERATOR hidden field in every HTML page rendered by .Net. If in a request received by the page, this hidden field is absent, or there was some error in the validation of the field's content then the request is not treated as a Post back.
If the request to the page is via a Server.Transfer, then it is not treated as a post back. There is an exception to this case, if the Server.Transfer to this page was initiated from this page itself then request is treated as a post back.
If the layout of the current page has changed since the last response, Page class will pretend that the request is a non-post back request. The layout changes are identified using the view state information received from the request. There are 2 view state related, .NET hidden fields in every response which assist in determining layout changes.
__VIEWSTATEGENERATOR
__VIEWSTATE
More information can be obtained from the source code for System.Web.UI.Page.IsPostBack property
The Visual Studio solution for this source code is also available for download

Calling a method/function from the code behind of a page im about to redirecting to?

I'm redirecting to a page like so:
Response.Redirect("Default.aspx");
Once this page loads up, and only if it loads from a redirect I want to enable a Panel.
What options do I have to do this?
What options do I have to do this?
Simplest would be to pass a parameter in QueryString and later in Default.aspx's page load check for that query string, if it is present enable the panel.
For sending:
Response.Redirect("Default.aspx?enablePanel=true");
For checking if the parameter exists.
string enablePanel = Request.QueryString["enablePanel"];
if (enablePanel != null && enablePanel == "true") //or parse to bool
{
//enable panel
}

Make User Control load before page

I have 3 parts to my site, Site Master, User Control (inside Site Master) and General page.
When a user logs in they are redirected to the General Page. The User Control is a dropdownlist of different accounts (Auto select first account) that get's their username and runs stored procedure to pull their information into a SiteID session Variable.
Then in the General page I set all the labels to the users information. with this code.
if (Session["SiteID"] != null)
{
SiteID = int.Parse(Session["SiteID"].ToString());
PopulateAccountData();
PopulateAccountInformation2();
PopulateSiteNodes();
PopulateSiteMap();
}
else
{
LabelSiteName.Text = "No Site Selected";
}
The problem is when the page loads for the first time it does not have the Session["SiteID"], I have to hit refresh for everything to load.
I am new to ASP.net so I'm not sure if I'm doing this right, but how do I get everything to load the first time?
Use : IsPostBack
Look : //www.java-samples.com/showtutorial.php?tutorialid=1083

How to redirect back if user did not get to page properly in C#?

I have a videoWall and a videoWallDetail page. Currently, this is what I have on the videoWallDetail page:
if (String.IsNullOrEmpty(Request["video_id"])) Response.Redirect("videoWall.aspx");
Users should not enter the detail page this way, but if they know the video id, some might go straight to the detail page by typing it into the url, so this will redirect users back to the videoWall page if they enter a video id in the address bar that is not valid. My question is how do I redirect back to the videoWall page regardless. If a user does not click on a link to get to the detail page of a particular video, they get sent back no matter if they enter a valid id into the address bar.
Thanks in advance!
You could add a Session on the videoWall.aspx page to verify they've come from that page:
videoWall.aspx
Session["fromVideoWall"] = true;
Response.Redirect("videoWallDetail.aspx?video_id=" + videoId.ToString());
videoWallDetail.aspx
if (Session["fromVideoWall"] != null && String.IsNullOrEmpty(Request["video_id"])) Response.Redirect("videoWall.aspx");
Session["fromVideoWall"] = null; //Setting the value back to null ensures the next access must have come from VideoWall.aspx too
1 You can use PostBackUrl method
And in the target page access to PreviousPage and get the data
Link : http://asp-net-example.blogspot.fr/2008/10/postbackurl-example-how-to-submit-page.html
2 You can also rewrite your url with HttpModule
Link : http://msdn.microsoft.com/en-us/library/ms972974.aspx
If i'm not allowed to just enter a known ID into the query string of the videoWallDetail page, then you shouldn't expose that as a query string param. What if I want to bookmark the page, or email someone a URL for them to go straight to? Are those disallowed?
If so, then you need to remove that querystring param. The URL bar should be a perfectly legal way for users to get around. If they can enter a URL to get to a page they shouldn't without a 400 or 500 error, then its YOUR fault as the developer.
Switch over to using a session variable or a form post to confirm they are coming from the proper place if they truly shouldn't be on Page B without having just come from Page A.

Categories