Is there a standard way to create unique web page address in ASP.NET? I'm sending surveys to customers and will be including a link to the web page. For example:
http://www.mysurveypages.foo/survey/UniqueID
I would then customize the survey based on who I sent it to. I know it can be done by passing in a unique parameter to a page but I curious about doing it this way.
You can use Routing to map your url structure onto a particular page and parameter collection. Essentially, it allows you to convert parts of the url into url parameters for your page. This works in standard WebForms and is the basis upon which MVC chooses the appropriate controller/action signature to invoke.
Yup like dcp said GUID is a reasonable solution http://mywebsite.com/survey.aspx?ID=GUID
Suppose you are going to sent the survey to a list of users.
List<User> users = GetSurveyUsers();
foreach(User u in users)
{
Guid guid = Guid.NewGuid();
//Then store the user-guid pair into DB or XML...
}
The simplest solution would seem to be making UniqueID an incrementing field that can be used to get the appropriate user information out of the database. You could use numbers, or a Guid, or some alpha-numeric value, it really doesn't matter.
If you go with ASP.Net MVC then it is quite easy to map the Url (like the one you specified) to a controller action which gets the ID passed in as a parameter. Otherwise you will probably want to look into some sort of Url rewriting to make sure the Url can be nice and pretty.
A GUID approach is safest, if you're able to store it somewhere. If not you could use some existing unique data (e.g. customer id or email address) either directly (but be careful about leaking sensitive data) or hashed (but need to consider collisions).
Related
I programed an application with asp.net and use "respons.redirect" in some pages, like this:
Response.Redirect(string.Format("~/*****/****.aspx?ID={0}", ID));
as user execute this cod he will redirect to correct page and every thing is fine .he can see this redirect link in his browser address :
http://localhost:1852/Jornal/Editor/ReviewerEmail.aspx?ID=1030
Now if he changes the ID manually and the ID is correct he can access the other data without any permission. how can i avoid this problem?(I wont use session)
please help me
If the ID needs to be public and no access control can solve the problem.
then i would suggest that you add a second parameter that is a hash of that Id.
Tampering with the ID parameter will cause a missmatch between ID and hash
http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256.aspx
you cold also change your ID parameter to a less 'guessable' id, like a GUID
You need to use access control.
Whenever you display any data, you need to check whether the currently-logged-in user has access to that data.
Obviously, you also need to track the currently-logged-in user, in a way that will prevent attackers from being able to claim they are someone else..
To do that, use ASP.Net's built-in membership system.
I am porting a legacy application to Symfony2 and I am struggling because routing doesn't include query string parameters. Some quick examples: Suppose you have a search page for books where you can filter results based on criteria:
http://www.bookstore.com/books?author=Stephen+King&maxPrice=20
The nice thing about query string parameters in a case like this is you can have any number of filters, use the ones you want for any given request, and not crowd the URL with filters you're not using.
Let's say we rewrote the routing for the above query using the Symfony2 routing component. It might look like this:
http://www.mybookstore.com/book/any_title/stephen%20king/any_release_date/max_price_20/any_min_price/any_format/any_category
Even not taking into account how arbitrarily long an unclean that URL is I still don't think it is as intuitive because each 'segment' of that route is not a key value pair but instead just a value (e.g. author=Stephen+King > /stephen%20king/).
You can of course access query string parameters in the controller by passing the Request object into the action method (e.g. indexAction(Request $request) {) but then validating them and passing them into other parts of the application becomes a hassle (i.e. where I find myself now). What if you are using the Knp Menu Bundle to build your sidebar and you want parts to be marked as .current based on query string parameters? There is no functionality for that, just functionality to integrate with Symfony2 routes.
And how to validate that your query string parameters are acceptable? I am currently looking at validating them like a form to then pass them into the database to generate a query. Maybe this is the way the Symfony2 team envisioned handling them? If so I'd just really like to know why. It feels like I'm fighting the application.
I ended up actually asking Fabien this question at Symfony Live San Francisco 2012. There was another talk at the same conference in regards to this question and I will share with you the slides here:
http://www.slideshare.net/Wombert/phpjp-urls-rest#btnNext
Basically in the slides you can see that the author agrees with me in that query string parameters should be used for filtering. What they should not be used for is determining a content source. So a route should point to a product (or whatever) and query string parameters should then be used in your controller to apply whatever logic you require to filter that content source (as per Fabien).
I ended up creating an entity in my application that I bind all my query string parameters to and then manipulate, much the same way forms are handled. In fact when you think about it it's basically the same thing.
Like in Symfony1, query strings are independent from the route parameters.
If you have a path defined as #Route("/page/{id}", name="single_page"), you can create a path in your view like this:
{{ path('single_page', { id: 3, foo: "bar" }) }}
The resulting URL will be /page/3?foo=bar.
We have several web applications that create a shopping cart, save it to a database, then redirect to a centralized web application to process and accept payment for the shopping cart. Right now, we are using GUIDs for the shopping cart IDs and passing those GUIDs in the querystring to the payment application. We are using GUIDs so that a user cannot easily guess the shopping cart ID of another user and simply plug that ID into the URL.
Now, using GUIDs in the database is bad for indexing and using GUIDs in the URL does not truly prevent a user from accessing another cart. However, using passing integers around would make it too easy.
What is the best and most secure way to pass the IDs from the individual applications to the centralized payment application?
I know that some people may say, "Who cares if someone else wants to pay for someone else's shopping cart?" However, we have the same concern when passing IDs to the page that displays the receipt and that page includes the customer's name.
You could pass the ID as an integer along with a "token" which would be a (cryptographically strong) hash of the cart ID and a random secret string. The payment processor would know the secret so it could perform the hash itself and compare to see if it is valid.
For example you can use the following (untested) code to create the token:
public static string GenerateHash(long CartID)
{
string SourceText = CartID.ToString();
//Salt the source text (secret)
SourceText += "5E95C91F7F947BD92ACA2CF81C3ADBD9B563839D85EA69F9DEA5A2DC330D0F50";
//Create an encoding object to ensure the encoding standard for the source text
UnicodeEncoding Ue = new UnicodeEncoding();
//Retrieve a byte array based on the source text
byte[] ByteSourceText = Ue.GetBytes(SourceText);
//Instantiate an MD5 Provider object
System.Security.Cryptography.SHA1CryptoServiceProvider SHA1 = new System.Security.Cryptography.SHA1CryptoServiceProvider();
//Compute the hash value from the source
byte[] ByteHash = SHA1.ComputeHash(ByteSourceText);
//And convert it to String format for return, also modify for URL use
return Convert.ToBase64String(ByteHash).Replace("=", "").Replace("+", "-").Replace("/", "_");
}
Pass the result of this function, along with your cart ID, since a hash is a one-way function that cannot be reversed. On the payment processor you would call the same function on the passed in cart ID and compare it to the token.
This will prevent tampering with the query string yet allow you to use integers.
Had you thought of POSTing to the central system and passing the values that way? Then they wouldn't be visible in your query string.
If you have to pass the GUID in the querystring, you could encrypt it to make it a little more secure. It will add a little overhead, also, to your processing.
You could also tie the user's cart to a cookie, then the GUID wouldn't be visible in the querystring and would be a little harder to detect (although using fiddler or some other tool like that would show what's being passed up and down).
I'd stick the identifier in a cookie, some other header or, if you have to POST, as a hidden value (like Lazarus suggested). I'd avoid having it on the querystring.
I would use methods similar to the Anti Forgery Token in ASP.NET MVC.
http://davidhayden.com/blog/dave/archive/2009/04/29/AntiForgeryTokenInMVCFramework.aspx
EG. In addition to your GUID, save a random id in a cookie and in the db tied to a user. Each time the user makes a http request check that the cookie matches with the database. It would be hard to get both the GUID and cookie correct.
I want to know what the best practice is for passing values (sometimes multiple values) between two asp.net pages
In the past I have used query strings to pass a value in asp like this:
href='<%# Eval("TestID","../Net/TestPage.aspx?TestID={0}") %>'><%#Eval("Title")%> </a>
I assume you can do this in the code behind but I do not know the best way.
I also assume it is possible to pass more than one value.
Could someone provide me with a VB snippet which would give me an idea of how to go about this?
You have many options for passing data and all of them can pass multiple values between pages.
You can use the Request.Form collection to capture values that have been submitted from an HTML form with the POST verb (i.e. " method="POST">).
The code looks something like:
Dim formvalue As String
formValue = Request.Form("FormField1")
You can also use parameters in a URL query string (much like you example):
Dim queryStringValue As String
queryStringValue = Request.QueryString("QueryStringValue1")
You can set a cookie (it's lifetime will depend on the Expiry property value that you set):
Setting a cookie (note: you use the HttpResponse object here. The user's browser stores the cookie when it receives the Set-Cookie HTTP header value from the response to a request)
Response.Cookies("CookieValue") = "My Cookie Data"
Response.Cookies("CookieValue").Expires = DateTime.Now.AddDays(1) ' optional, expires tomorrow
Retrieving a cookie value (we use the HttpRequest object here):
Dim cookieValue As String
cookieValue = Request.Cookies("CookieValue")
You can use the HttpSessionState object (accessible via the Session property of a page). To set a session variable:
Session["SessionValue"] = "My Session Value"
To retrieve a session value:
Dim sessionValue As String
sessionValue = Session["SessionValue"]
There's another way to pass page state between pages using Page.Transfer (see How to: Pass Values Between ASP.NET Web Pages), but I'd try and get comfortable with the above before looking into that.
As far as best practices go it really depends on what data you're passing.
Don't pass sensitive data via URLs (query strings), forms or cookies. These can intercepted in various ways
Pass sensitive data using a server-side store (like session state or a database) but consider how to keep the session ID safe.
Never trust data from outside your application (data that users have entered via a form, information read from a database, etc.). Always encode this information before displaying it again in your pages. This prevents against Cross-Site Scripting (a.k.a XSS) attacks.
Don't use sequential IDs in query strings where you're passing user-specific identifiers between pages. Say you create an Orders.aspx page that lists all orders for a customer. You pass in a CustID parameter via a query string: Orders.aspx?CustID=123. It's easy for someone to change the URL to Orders.aspx?CustID=124 and view information they shouldn't. You can get around this by doing a check that the current user is allowed to see the information, you can use an identfier that can't be easily guessed (commonly a GUID) or pass the information on the server-side.
It would help you to check out the following links:
a. Cross page postbacks
b. How to pass values between ASP.NET pages (MSDN)
c. Another article by Steve C. Orr on Passing values.
You can use a session, cookies, the query string, hidden form fields in a post request.
We heard a lot about the vulnerabilities of using QueryStrings and the possible attacks.
Aside from that, yesterday, an error irritated me so much that i just decide to stop using QueryStrings, i was passing something like:
Dim url As String = "pageName.aspx?type=3&st=34&am=87&m=9"
I tried to
Response.Write(url)
in the redirecting page, it printed the "type" as 3, then i tried it in the target page, it printed 3,0....i know this can be easily dealt with, but why? i mean why should i pass 3 and have to check for 3.0 in the next page's load to take my action accordingly???
So what should we use? what is the safest way to pass variables, parameters...etc to the next page?
You could use Cross-Page Postbacks.
Check also this article:
How to: Pass Values Between ASP.NET Web Pages
There are many options you can use, most of them requires you to build a strategy to pass variables between pages.
In most projects I use this strategy, I create a formVariables class to hold currently active items. it has properties which you will need to pass by querystring. and I store this class at session. and in my base page I read it from session. so in every page I get values over this object. the only negative thing about this method is to clean up items when you finished your work on it..
hope this helps.
I would sugest you avoid using Session to pass variables between pages as this breaks the stateless model of the web.
if you have just stored some values in session that relate to a certain page then the user uses their browsers back button to go back to the same page whcih should have a different state then you are not going to know about it.
It leads to the possibility of reading session values that are not relevant to the page the user is currently viewing - Which is potentially very confusing for the end user.
You will also run into issues with session expiration if you rely on it too much.
I personally try to avoid using session where possible in preference of hidden form values + query strings that can be read on postback + navigation.
The best / most secure way to pass info between pages is to use the session.
// On page 1:
this.Session["type"] = 3;
// On Page 2:
int type = (int)this.Session["type"];
You can store any kind of object in the session and it is stored on the server side, so the user can't manipulate it like a query string, viewstate, or hidden field
You said:
it printed 3,0....i know this can be easily dealt with, but why? i mean why should i pass 3 and have to check for 3.0
There's a difference between "3,0" (three comma oh) and "3.0" (three point oh). You also said that you were "passing something like".
In a query string, if you pass multiple values in the same key, they will be seperated with commas.
As all values are passed as strings there's no way that an int "3" is going to magically become decimal "3.0" unless you parse it as such when you request it.
I'd go back and double check what you are passing into your URL, if it ends up as something like:
pageName.aspx?type=3&st=34&am=87&m=9&type=0
Then when you read back
Request.QueryString["type"]
You'll get "3,0" back as the comma seperated list of values in that key.
First, in asp .net you can use several strategys to pass values between pages. You have viewstate too, however the viewstate store the value and the use is in different scenarios , you can use it too. Sessions instead, and of course by post in a form.
If your problem is the security, I recommended you to create 2 users for accesing the data. One user with read only access, this for accessing the pages ( Sql Inyection prevent ) and validate the data throw the querystring. And One with write access for your private zone.
Sorry, for my unreadeable English.
I like to use query string as I like users to be able to bookmark things like common searches and the like. E.g. if a page can work stand-alone then I like to it to be able to work stand-alone.
Using session/cross-page postbacks is cool if you needed to come from another page for the page you're on to make sense, but otherwise I generally find querystrings to be the better solution.
Just remember that query strings are unvalidated input and treat them with the caution you would treat any unvalidated input.
If you do proper security checks on each page load then the querystring is fine and most flexible IMHO.
They provide the most flexibility as the entry poitn to a page is not dependant on the sender as in some other options. You can call a page from any point within your own app or externally if needed via querystrings. They can also be bookmarked and manually modified for testing or direct manipulation.
Again the key is adding proper security and validation to the querystring, and not processing it blindly. Keep in mind that the seucirty goes beyond having edit or read access, depending on the data and user, they may not have access to the data with thos paranters at all, in cases where data is owned and private to specific users.
We have tried various methods, in an attempt to hide the querystring but in the end have gone back to it, as it is easier to do, debug, and manage.