I have following ajax call
open: function () {
$(this).load("MyBox.aspx?sec=L&levId=" + RowId);
}
so people can see the querystring, so the user can copy url and paste it to browser but how can i block that? I dont want it to shown from browser. How I can do that? I m using asp.net and jquery.
load function issues a GET request. Instead of that, you may use a jQuery POST call and get the data. Users can't get the result by pasting it in browser and hit enter (which is GET request)
var thatObject=$(this);
$.post("MyBox.aspx?sec=L&levId=" + RowId,function(response){
thatObject.html(response);
})
In the server page, you can read the values posted by checking the Request.Form collection (instead of Request.QueryString).
from msdn
The Form collection retrieves the values of form elements posted to
the HTTP request body, with a form using the POST method.
You can determine whether the call is a GET call or POST call by inspecting the Request.RequestType property value. This way you can avoid people issuing GET request to this method and getting the response.
But remember that, there are tools/browser addons which does the POST request from browser.
Also if the data is for authorized users, you may check the user is authorized to access it in the server page(MYbox.aspx) before returning the content.
You can't. You can never trust any code running on the client. If you need to hide data on the client, you should create a server based session and then put a session token in an encrypted cookie.
From wikipedia and W3C
Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter.
Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe.
By contrast, methods such as POST, PUT and DELETE are intended for actions that may cause side effect
If your get request changes the state of the server (which it most likely does based on your post), you are doing something wrong. What you're trying to do is impossible. You need to rethink your architecture.
Related
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.
Assume you have a page in ASP.NET where it makes sense to use JavaScript/jQuery to modify the DOM with values that will eventually be read by the server on submit. For example, you have a form that allows end users to add/remove objects (like dependents on a health insurance form or assets on a loan application).
What are some ways to ensure that these items are detected and retrieved by the server once the information is submitted?
I've tried a few things that work, but none of them seem perfect so I wanted to see what the community had to offer.
Also, I'm not looking for suggestions that avoid dynamic DOM elements (like use a Wizard, etc.). I'm specifically trying to improve my technique with dynamically created DOM elements.
There are two ways to do something like this:
First: post only the information on submit. As long as you add both a name and an id attribute to every element in your DOM, every element is represented in Request.Form, so you can easily iterate through this collection.
I tend to have a naming convention like insurance_row_1, insurance_row_2 and so forth. You can find all rows like Request.Form.AllKeys.Where(k=>k.StartsWith("insurance_row_")).
When you want to save every action on the server:
Maintain a state container in javascript, that holds information in some dictionary-like control, where you put every action that has been performed by your application, and a state whether the server has processed them. Something like:
var stateContainer = [
{ 'put-insurance-row-1', false },
{ 'delete-insurance-row-1', false }
];
Do an AJAX request to the server to perform such an action, and use the state-container's key to track whether the request succeeded or failed. Set the state to 'true' when the request has been successfully submitted. Make sure to do this in order in which you receive the events, so send them one-by-one to the server to ensure that you keep a valid state.
You can (try) to prevent closing the browser if some states aren't persisted yet.
why are you using client side code to do this? i would go the route of doing a postback and adding a control from server side code. the built in ajax updatepanel should handle this very quickly.
For a website I am building, I am using jQuery to post data to Generic Handlers I created for this purpose.
Because you need to be logged in, to do most post actions (like 'rate a picture'), I am currently using the following technique:
User visits page
Page determines if user is logged in
On Page_Load the page fills a hidden field with an encrypted string, which contains several needed variables, like User ID, Picture ID (of the picture they are currently viewing), the DateTime when the page was rendered.
When the user clicks a "I like this picture"-button, I do a $.ajax post to my Generic Handler, with the encrypted string and the value whether or not they liked the picture.
The Generic Handler decrypts the supplied encrypted string and takes a look at the DateTime to determine if it was not too long ago
When everything works out, the vote is submitted to the database.
In my understanding this is a pretty secure way to handle a situation like this. But maybe I am missing a very important point here.
Any advice would be very welcome.
Looks okay to me.
It looks like you're using a token pattern, a good method with which to secure stateless communications.
You should remember that $.ajax calls to your Handler will also support native ASP.NET security mechanism. When you perform $.ajax the .ASPXAUTH cookie is being add to cookies collection, so you can check in your Handler for this cookie, check HttpContext.User and limit access to the path of your handler in web.config - this all works.
I have an action-method in a controller that takes requests coming from a variety of different views.
It is somewhat of a utility method and I simply want it to accept the parameters it is given - do something - and then refresh the view that sent the request.
Right now, the only way I see to do this is by having the method figure out what view sent it the info and do a:
return RedirectToAction("method", "controller");
For each possibility (or something similar to that).
Is there a more general way I can make my method just re-render the current view without having to explicitly identify it?
-Thanks
Your best bet is to use jQuery to post the data then utilize the results as you see fit. Otherwise you can pass in the action/controller name in the post and use them dynamically to redirect.
The background to this question is that I need to use some user session data in a (static) WebMethod. I have created a static property that references the data I need like so:
private static UserWebSession UserWebSession
{
get
{
return (UserWebSession)HttpContext.Current.Session["UserWebSession"];
}
}
I can then call this in my page's static WebMethod.
My question is, is this technique thread safe? Or will this property's value be updated with every new page request - in other words, it will return the UserWebSession for the user who most recently requested the page?
That's fine - HttpContext.Current is designed precisely for this sort of thing. You won't get a previous user's session.
It's dependent on the thread though (I believe) - so if you start any extra background threads, they won't be able to see the current context.
Also be aware that although this call is safe in terms of not getting the wrong context, the normal concurrency caveats apply when it comes to what you actually do with the context.
I don't know that a Page Method is able to access Session state. If it can, then you may be ok. I recall that access to Session state is serialized, so that only one request at a time can arrive for a given session.