I have spend a lot of time on this problem without any change :
I have got 2 simples apsx page, in the first page the
Page_Load event put data in the session ;
later the on_click event of a button fire an HttpWebRequest to the second
page
with the idea to retrieve on the page_load of the second page the data in
the session.
to sum up : 1st page put data in session, make the httpWebRequest to the 2nd
page
2nd page : try to get the stored data in the session.
This is the different attempt of code i 've tested to perform this action,
the result was always the same. When i try to add sessionId Information (via
a cookieContainer or directly in the Header request) i get a timeout exception
System.Net.HttpWebRequest.GetResponse() and when i do the HttpWebrequest
without the session_id information i get the response immediatly but without
the session info :-)
It's not clear what you're trying to do, but have you considered using Server.Execute instead?
http://www.west-wind.com/weblog/posts/2004/Jun/08/Capturing-Output-from-ASPNet-Pages
Related
I have several ASP.NET pages that store an object in the session and use it for data binding etc. The object in the session is referenced in several pages of a 'wizard'.
I want users to be able to have several tabs open and work on several different objects stored in the session at the same time.
I am using a URL param to do this, where the param is incremented each time the page is hit, i.e:
http://server/MyPage.aspx?action=1
http://server/MyPage.aspx?action=2
And my session access is simply
return (MyObject) Session["MyObject" + Request.Params["action_id"]]
This is fine, but it doens't work for object data sources when they are data bound - the error is "Request is not available in this context"
How can I get an ID that I can retrieve on the server side reliably in callbacks and page loads? The ViewState doesn't seem to be available in
Ah, the trick is to use
System.Web.HttpContext.Current.Request
Is there a way to save the querystring ids after the page load? the reason why i am looking is that ...i should be back and forth with pages and more importantly if the user try to manupluate the ids then it should not effect the result of my page since i will be reading the Ids not from querystring but from some save prop or something like that.
for an example: let says the page loads very first time... i have this url:
http://www.somesite.com/Shop/Product/Detail.aspx?ProductId=100
and if the user try to modify the querystirng and re-load the page then the page_load should not read from querystring rather from saved prop or something???
In your page load event look at the Page.IsPostBack property. It is false when a page is first loaded. You should validate your parameters then and perhaps save them to session or viewstate.
If Page.IsPostback = false Then
'Validate Request("ProductID") here
'Save in viewstate or session state
Else
'Retrieve ProductID from viewstate or session state
End If
If a user changes the query string, you should consider it a new page load.
This would not work since it's against the very basic nature of Internet. Internet is stateless.
Everytime user changes the querystring, it will be treated as a new Url, storing the parameters will be of no use. Page.IsPostback won't work either since every Url change will be a first hit.
Saying that, you can still work around it,
With every Url, you can pass a unique identifier (like a GUID.)
As soon as page hits, you can save parameters in session and work with them and use the Guid to map the two requests.
But the problem remains here, if the user changes that Guid then again it will be treated as a new request. You can go one step ahead and start saving that GUID to make sure that only system generated GUIDs are handled but overall it will just make your system complex.
My guess is that you might be looking at a wrong solution for your problem. If you can share your actual aim then we might be able to recommend you something more tangible.
You can not stop users from editing querystring values and trying to see content of another page or execute something. what you can do is you can check in the page load that this user has sufficient permission to access this page.
Ex : www.mysite.com/editproduct.aspx?productid=4
In editproduct.aspx, you have to check whether the product 4 has access by the current user who is accessing the page.( May he should be the creator/ he should be in a specific power users group etc... depending upon your scenario). If he has access, show the edit form to the user, else hide it and show a message saying "you are not authorized to access this resource."
There is no way; however, you can use session to validate when the Page_load is called.
If ( Page.isPostBack = true ) {
Session("SAVE") = false;
}
For a while in the before the Request.Querystring statement, you validate the 'save' session state.
I have a master page where I'm loading some data into the session.
I put the lines of code that call my queries in the Page_Init event of the master page, inside an if statement
if (!Page.IsPostBack){ load data from queries into the session }
Is this what I need for all the session data to be loaded only once per session. What about call backs? Do I also need to check to avoid a reload of session data on call backs? Any other condition I need to check to avoid unnecessary reloads of session data? I'm looking to run the queries inside the condition statement only once.
Thanks.
No. What you just posted won't guarantee that will be called once per session. In fact, every time your ASPX page is invoked with a GET command, the data will be loaded.
If you want data to be loaded just once by HTTP session (I am assuming by session you mean HTTP session) then try Session_OnStart event handler.
You can check to see if the session variable is null. If it is null then load the data. If it is not null then do nothing.
As Pablo Santa Cruz suggests, the best place to load the session variable is in the Sessio_OnStart event handler but a quick and dirty way is to simply check for the sessions existence in the Page_Init event.
The problem is I redirect to a sub page from the main page by passing a few values in Request.
I need to get back the value I got from manipulating values I sent in request and I don't need to store value in Session.
You can use the PreviousPage property, depending on how you got to the new page.
There are a number of things you can do:
Page.Request["ID_Of_Control_You_Are_Interested_In"] will get you a value that you need.
If you Server.Transfer to the page you can call Context.Handler, cast it to the page you come from and traverse the controls collection to get your value.... (similar to PreviousPage property)
You can also inspect the Query string parameters sent in the request too:
Page.Request.QueryString("Param_To_Inspect")
you can return your values as JSON as the response and then using a jquery to get the data
You have three options: Query String Parameters, Cookies and Session State
Query String Parameters: http://www.aspnet101.com/2007/11/using-the-querystringparameter/
This is a good way to pass data between pages. It's the most commonly used and is limited to the max length of the url.
Cookies : http://msdn.microsoft.com/en-us/library/ms178194.aspx
This is a good method. It also has a size limitation. The advantage of cookies is you can persist data that can span visits to your site.
Session State : http://msdn.microsoft.com/en-us/library/ms178581.aspx
This an ok method, I'd use the two methods above before I would use session state. In my experience you can get into trouble very fast with Session state.
To answer your question: You can take the value from the request and load it into a TextBox. Then on the web page, the user edits the value and clicks a save button, which posts the changed value back to the server.
Or you could use javascript to post the value back to the server.
i want a handler to redirect to a web-forms page, pre-filling in the values of some controls on the form.
i tried setting my current Request.Form data:
if (theyWantToDoSomething)
{
//pre-fill form values
context.Request.Form["TextBox1"] = "test";
context.Request.Form["ComboBox1"] = "test 2";
context.Request.Form["TextBox2"] = GetTheTextForTheThing();
//tell the client to go there
context.Response.Redirect("~/SomeWebForm.aspx");
return;
}
But i get an exception that Form values are read only.
What would be a way to send the client to another page, pre-filling form data?
Answer
i used the Session state to store values. It's important to note that by default a Handler doesn't have access to Session (the Session object will be null). You have to tell IIS to give you the Session object by adding the IRequiresSessionState marker interface to your handler class:
public class Handler : IHttpHandler, System.Web.SessionState.IRequiresSessionState
{
public void ProcessRequest(HttpContext context)
{
...
if (theyWantToDoSomething)
{
//pre-fill form values
context.Session["thing1"] = "test";
context.Session["thing2"] = "test 2";
context.Session["thing3"] = GetTheTextForTheThing();
//tell the client to go there
context.Response.Redirect("~/SomeWebForm.aspx");
return; //not strictly needed, since Redirect ends processing
}
...
}
}
You can only populate your Response, the Request is input data and is indeed read-only.
If you are using ASP.NET, there are a variety of ways you could accomplish what you need:
The best way would probably be to pass the data you need to be pre-populated to SomeWebForm.aspx via the Session object, and on that pages Load method, populate your form. Keep in mind that when you do Response.Redirect, a 302 response is sent to the client with the URL the client should redirect to. The process is transparent to the user...but there is a full round trip involved.
Another alternative to populating the users Session would be to add GET parameters via a query string to the redirect to SomeWebForm.aspx.
If you need to transfer processing to the SomeWebForm.aspx page without round tripping, you could use Server.Transfer. This will transfer execution from the current page to the page you choose...however, this can cause some odd behavior on the client end because the URL does not update. As far as the user is concerned, it will still appear as though they are on the same page they started on.
A few ideas that might get you started:
Pass the values in the query string
Store the values in the session state or in a seperate cookie
Store the values in HttpContext.Items and use Server.Transfer instead of Response.Redirect
Another approach that hasn't been mentioned yet is using Server.Transfer makes it possible to use the Page.PreviousPage property, allowing access to the controls on the page that transferred control.
As jrista mentioned though, using Transfer doesn't update the URL shown to the user, which may or may not be an issue. For example, a user can't precisely bookmark a page they got transferred to since the URL will be that of the original transferring page.