ASP question

Beëlzebooze

I am (trying) to write a small web application for the company I work for, and I am stuck on a particular aspect of it.

Basically what happens is a user logs on to the application and is presented with data they have entered into a database, based on their own userid. The data they are shown is only a small selection of the actual data, for example, they are shown the IssueID and a description of a problem.

What I would like is for the IssueID to be clickable, in the table of items, so that I can then call an ASP page, which will select that particular issue and return all data regarding thar one issue.

Now I have seen that it is possible to send additional data allong with an <a href= > or something similar, for example look in the addressbar when browsing boards.ie you will see for "...newthread?s=...." etc.

I could have my code generate this like so:
table_content = "<TR><TD><a href =" & """" "doodlysquat.asp?" & oRs("ID") & etc. etc.

But how do I read the information I send with the redirection?

how does my doodlysquat.asp read the name and value of what I am sending along?

please no javascript, as I am not a programmer, I am tryng to get to grips with VBscript, and I do not need antother distraction.....

Thanks...

Beëlzebooze

o yeah,

and what is the correct terminoligy for the "?" it's difficult to google something if you don't know what it is called......

(don't say it's a question mark!)

Bard

The "?" and everything that follows it is the 'query string'. It sounds to me like you want to be able to pass a variable name and value from one asp page to another via the query string.

This is a fairly simple operation and is covered by a number of web tutorials. I'd suggest you read a few, or grab a good book on ASP.

e.g.: search in google

or try this example:

put the following code in a file called mypage.asp :

<%
mydata = Request.QueryString("myname")
Response.Write "Your name is " & mydata
%>

Then go to that page by referring to it with something like:

http://www.yourdomain.com/mypage.asp?myname=FANTASTIC FRANK

(where yourdomain.com is... your domain)


... hope this helps...

Beëlzebooze

I cannot believe it's that easy......querystring......who would have thought it,

Good man Bard!
Thanks!

davej

Check out RFC 2396 for a description of what the question mark (amongst other things) is. I guess you'd call it a "uri path-query delimiter" or the "question mark delimiter".

This type of transaction is called a HTTP GET, where parameters get passed to the web server by being encoded in the uri.

As for how to get access to the parameters and values, well that is very basic asp and has been answered above. But you should really read a basic tutorial on how it's done..

davej

Bard

Using the POST method is, of course, more secure. The variables are still filled and transferred over to the next script, but they're not visible to the user in the query string.

Have a look at tutorials showing how you can use forms to submit data from one page to the next via POST.

Google is your friend

davej

Using the POST method is, of course, more secure.

It isn't really more secure at all. Also with POST, specific pages can't be bookmarked or referred to. That's why, for example, boards.ie or amazon uses the GET method depending on what they want to do.

davej

Talliesin

Originally posted by Bard
Using the POST method is, of course, more secure.

POST is no more secure than GET. If someone wants to mess with POST data they can do so just as easily as with GET data.

Any system that transmits information to and/or from the client that the client shouldn't see is 100% insecure, end of story.

The primary differences between GET and POST are:

Semantic:
"GET" should generally be idempotent (repeating the same GET should result in essentially the same action).
In REST terms GET results in obtaining a representation of the resource identified by the URI.
GET is "free", GET implies no action or commitment, GET is "just looking".

POST may quite sensibly result in completely different results for the same POST data (though it doesn't have to).
In REST terms POST sends data to a resource identified by the URI and obtains a representation of the results (which may or may not be a representation of the resource as changed by the POST).
POST implies action or commitment, POST is "doing".

Usability:
GET allows the user to alter the URI to turn it into another GET. This is a good thing, it's the user's choice after all. Ideally GET URIs should be designed to make this easier (e.g. sensible hierarchies in URI structure).
POST doesn't have this usability advantage.

Technical ability:
GET can only send textual data. It is limited in extent (typically to around 4k in size) and becomes unweildy long before that.
GET responses can be cached, though they don't have to be. If it won't cause problems caching should be encouraged (send appropriate headers, and have your ASP pages correctly send Last-Modified headers and respond with 304 Not Modified when appropriate).

POST can send binary and textual data. It can send a theoretically unlimited quantity (although POSTs that may result in more than a few dozen kilobytes of data need to be handled differently to how they typically are by ASP, although it can still be done in ASP).
Caching of POST data is extremely limitted, and generally not possible.

spod

Best practices for input validation with Active Server Pages
by our very own ecksor is also well worth reading.

If it's going to be an Internet accessible application, make it mandatory reading.

Bard

Apologies if I was unclear, - what I meant by the POST method being more secure was in that it doesn't make the variables and values visibly available in the query string. This makes the transmission of items such as passwords, etc. more secure in that they are safe from, well... someone looking over the web site users shoulder...

spod

Originally posted by Bard
...what I meant by the POST method being more secure was in that it doesn't make the variables and values visibly available in the query string. This makes the transmission of items such as passwords, etc. more secure in that they are safe from, well... someone looking over the web site users shoulder...

heh

funny

you are joking, right?

ecksor

Originally posted by Bard
This makes the transmission of items such as passwords, etc. more secure in that they are safe from, well... someone looking over the web site users shoulder...

More to the point it stops data being leaked in the form of referrers, or appearing in website log analyser output and that sort of thing.

Talliesin

Originally posted by Bard
what I meant by the POST method being more secure was in that it doesn't make the variables and values visibly available in the query string.

Fair enough I suppose, though logging-in to a system is also a case where you want the "doing" of a POST rather than the "looking" of a GET, so the possibility of using a GET never comes up.

The Corinthian

Originally posted by ecksor
More to the point it stops data being leaked in the form of referrers, or appearing in website log analyser output and that sort of thing.

Or a usr/pwd in the url being cached in the browser.

Bard

Originally posted by spod
heh

funny

you are joking, right?

Are you one of those people who points and laughs at people saying "you're wrong" without actually explaining why?

If you can be bothered, do enlighten me... What's wrong/funny about what I've said?

JohnK

I'd like to know as well. I can think of one example offhand where my userid and password were sent in clear text in the address bar of IE. It was with an online photo album. There is a program that makes it easier to upload your pictures from a digital camera(or any image on your pc). It stores your login name and password in the program and thats grand. The problem is that when the upload is done it asks you do you want to view the site with your recently uploaded pictures. If you click yes it opens a new browser window and the address bar has something like http://www.website.com/album.asp?userid=bob&password=abc123
That’s not very secure since its now cached in the browser’s history file and anybody who uses that computer can see my username and password.

ecksor

I think the point is that while it is dangerous for all the reasons mentioned, the looking over the shoulder thing isn't the most relevant point. Firstly because the data is recoverable and leakable through several other channels, and secondly because if someone is looking over your shoulder then they can see you physically typing the username/password anyway.

Talliesin

The case JohnK mentions would be a misuse of GET before you consider security anyway. The very nature of GET means you aren't doing anything like logging in.

Kernel32

First of all, no useful information, such as a username or password should ever be passed from a client browser to a server except for a login page, from then on it should be a unique session identifier such as a guid.

Secondly, just use Request("myvar") , then if myvar comes in through the querystring or a form post it won't matter, it will read either, querystring being default I believe, could be wrong on that.

Talliesin

Originally posted by Kernel32
Secondly, just use Request("myvar") , then if myvar comes in through the querystring or a form post it won't matter, it will read either, querystring being default I believe, could be wrong on that.

Yep, at the penalty of a slight performance hit Request("myvar") will give you that behaviour.

However unless the page has actively been designed to respond to the very different semantics of POST and GET in pretty much the same way (can't work out why you might want to do that) then it would probably be preferable to report an error when someone POSTs to a page intended only for GETting, and either an error or a representation of the service the POST performs if someone GETs a page intended for POSTing to.