Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 26
  1. #1
    Regular Coder
    Join Date
    Sep 2002
    Location
    South East UK. 35 miles east of London, in sight of the River Thames.
    Posts
    300
    Thanks
    10
    Thanked 0 Times in 0 Posts

    Testing the origin of the refering page

    Hi All,

    I am an asp newbie so please bear with the following problem description.

    I need to test the url of the previous page to the one displayed. That is, I need to know the url of the page that called the one currently on the screen, so that I can test it to prevent people accessing the site from 'bookmarks', etc.

    I have tried javascript and now know that document.referrer is not reliable across all versions of IE and that you can't get at the 'History' function anymore.

    I have read that 'session.variables' may be used to solve this, but that is as far as I have got. I can use asp to search/report a database but that is the limit of my capabilities at present.

    Any idea's/polite suggestion? :-)

    Regards

    Gary

  • #2
    Supreme Master coder! glenngv's Avatar
    Join Date
    Jun 2002
    Location
    Philippines
    Posts
    11,075
    Thanks
    0
    Thanked 256 Times in 252 Posts
    use request.servervariables("HTTP_REFERER")
    Glenn
    ____________________________________

    My Blog
    Tower of Hanoi Android app (FREE!)
    Tower of Hanoi Leaderboard
    Samegame Facebook App
    vBulletin Plugins
    ____________________________________

  • #3
    Regular Coder
    Join Date
    Sep 2002
    Location
    South East UK. 35 miles east of London, in sight of the River Thames.
    Posts
    300
    Thanks
    10
    Thanked 0 Times in 0 Posts
    Hi Glenn,

    Tried that, but HTTP_REFERER doesn't work with all versions of IE.

    Thanks

    Gary

  • #4
    Regular Coder
    Join Date
    Mar 2003
    Posts
    176
    Thanks
    0
    Thanked 0 Times in 0 Posts
    If you have a login page, you can set a session variable when they have sucessfully logged in - eg:

    Session("isLoggedIn") = true

    When the session expires, the session variable is destroyed (ie. session variables have session scope). If the user logs out, I set the session variable values to "" (zero-length string) - I should probably set them to equal Nothing and call Session.Abandon as well, but I don't bother (is there a reason that I should, anyone??)

    In your other pages, you have a procedure that checks to see if that particular session variable exists.

    If it doesn't exist when they try to visit a page that requires the session variable to be true, they get redirected to another page (login for example). If it does exist, well, their session is current and they can access the page.

    If a user bookmarks a page and visits from the bookmark (and they don't have a current session), they get redirected to wherever. (login.asp say)

    As you can see, this method assumes a login process - but that need not be the case. For example, you can set a session variable to equal the url of a page and read that Session variable on another page like this:

    --
    page001.asp
    --
    Code:
    Session("strUrlReferer") = Request.ServerVariables("URL")
    --
    page002.asp
    --
    Code:
    Response.Write Session("strUrlReferer")
    The value of Session("strUrlReferer") should change with each page that has code like page001.asp (I haven't tried it though), so that when you actually ask for the Session("strUrlReferer") value (as I did in page002.asp above), it's value should be that of the refering url.

    If the value of Session("strUrlReferer") is empty (or a particular value that you want to know about), then you can redirect (or whatever) as described for the login method.

    But this only works for pages in your own site (as does the login process above)
    Last edited by HairyTeeth; 10-10-2003 at 04:57 AM.

  • #5
    Senior Coder
    Join Date
    Jun 2002
    Location
    41° 8' 52" N -95° 53' 31" W
    Posts
    3,660
    Thanks
    0
    Thanked 0 Times in 0 Posts
    IE shouldn't have anything to do with it anyway, unless cookies are disabled.

    Then it's a problem because if cookies are disabled, Session variables won't work in ASP.

    raf's other solution is definitely thinking outside of the box, and sounds like it would work. But before you go with that method, I'd double-check your assumption that HTTP_REFERER doesn't work with whatever browser, because it's server-side code!

    What that means is that it doesn't matter what browser you're using. The only thing I can see that could possibly affect regarding client-side code and HTTP_REFERER is the following:

    1. There is no referrer (easy enough to check for)
    2. Cookies are disabled on the client's browser (also easy enough to check for - set a cookie, and see if it exists!)

    I'd look at those two things first, and then go from there.
    Former ASP Forum Moderator - I'm back!

    If you can teach yourself how to learn, you can learn anything. ;)

  • #6
    Regular Coder
    Join Date
    Oct 2003
    Location
    London, UK
    Posts
    411
    Thanks
    0
    Thanked 1 Time in 1 Post
    Gary, referrer URLs have nothing whatsoever to do with cookies.

    The only connection between them is that some "privacy" apps and/or firewalls block or interfere with them. This means that you *cannot* rely on a referrer URL being available (or not)!

    In any case, you're barking up the wrong tree - Hairyfew has already provided the correct approach, i.e. to create a login system which sets a session variable, which is then checked at the top of each page that you need to protet. This DOES require cookies to be enabled, but since 99% of modern sites need them, any user disabling them is causing his own problems, and I suggest that should not be your concern.
    Marcus Tucker / www / blog
    Web Analyst Programmer / Voted SPF "ASP Guru"

  • #7
    raf
    raf is offline
    Master Coder
    Join Date
    Jul 2002
    Posts
    6,589
    Thanks
    0
    Thanked 0 Times in 0 Posts
    raf's other solution is definitely thinking outside of the box, and sounds like it would work.
    Hey thanks whammy. (though you've gotten me realy confused now )

    Anyway : request.servervariables("HTTP_REFERER") is useless for what you try to do, because it will only contain a value if the client clicked a link to request your page. If he clicked a bookmark or types in the pageadress, that variable wount even be in the servervariables-collection.

    The only two alternatives are sessions (but they need cookies) or storing there IP in a db.
    But this second method has the disadvantages that there are providers (like AOL) that assign another IP number to each pagerequest ...
    So what you need to do is :
    - on top of the page, check if a sessionvariable is set
    - if not, run a select agains a table in your db with all IP's of active sessions. If found --> display page (there is an incredibly wmall chance this will be a 'false hit' of a second AOL surfer, but that chance is so slim ...
    - if IP not found, set a cookie and store the clients IP in a sessionvariable and then redirect to another page with the IP adress in the querystring and read the cookie --> if the cookie is set, redirect to the loginform.(after a succesful login, set the sessionvariable you test on on top of each page). If the cookie isn't set, display a message that he will only be able to continue if he has a 'stable' IP (so no AOL users) and provide a link to a third page, again with the IP in the querystring.
    - on this third page you compare the IP of the request with the value in the querystring. If they match, create a record in the sessiontable

    I wrote something similar in PHP recently, but if i were you, i'd just require users to have cookies enabled, because it becomes a lot more complecated and resource eating to apply this hack...

  • #8
    Senior Coder
    Join Date
    Jun 2002
    Location
    41° 8' 52" N -95° 53' 31" W
    Posts
    3,660
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I agree... but using the HTTP_REFERER is a good way to make sure first of all that some wannabe hacker isn't creating his own HTML form to post to your website. Just check the ServerVariables collection and make sure you know where this post is coming from.

    If using cookies is a problem, I'd perhaps provide a blurb on your website as to why cookies must be enabled.

    The same type of thing is required on most websites - after all, it's the easiest solution, and probably the best. Anyone who knows how to disable cookies should be able to figure out how to enable them as well.

    I require cookies on all of my sites, just for login purposes (and these don't necessarily use Session variables).

    P.S. raf, your solution is so confusing and unnecessary (although you might have noticed something I didn't), that I quit reading it. It's much simpler than that, I think.

    Why use two or three methods (let alone involving a database) when you can just check a cookie?
    Last edited by whammy; 10-15-2003 at 03:23 AM.
    Former ASP Forum Moderator - I'm back!

    If you can teach yourself how to learn, you can learn anything. ;)

  • #9
    Regular Coder
    Join Date
    Mar 2003
    Posts
    176
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Originally posted by whammy
    raf's other solution is definitely thinking outside of the box, and sounds like it would work.
    um... raf hadn't made a post at that stage. Were you refering to another thread?
    Last edited by HairyTeeth; 10-15-2003 at 05:17 AM.

  • #10
    raf
    raf is offline
    Master Coder
    Join Date
    Jul 2002
    Posts
    6,589
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Originally posted by whammy
    I agree... but using the HTTP_REFERER is a good way to make sure first of all that some wannabe hacker isn't creating his own HTML form to post to your website.
    There are more secure ways to achieve that. I'm not even sure checking the referer will stop them. Besides, this was the original question:
    I need to test the url of the previous page to the one displayed. That is, I need to know the url of the page that called the one currently on the screen, so that I can test it to prevent people accessing the site from 'bookmarks', etc.
    so it though i should point out that the referer-servervariable is empty when the page is requested through a bookmark or types in url
    I require cookies on all of my sites, just for login purposes (and these don't necessarily use Session variables).

    P.S. raf, your solution is so confusing and unnecessary (although you might have noticed something I didn't), that I quit reading it. It's much simpler than that, I think.

    Why use two or three methods (let alone involving a database) when you can just check a cookie?
    Well, i don't have any userrequirements and can still achieve the same functionality, unless they don't have a stable IP. It's just a more universal method, and is a typical case of 5 - 95 --> 95% of the code is needed for this extra 5 percent of users.

    But as i pointed out in my closing comment ; i don't recommend it.


    It's a lot of overkill if it is just to check the referer. I also use this session-table:
    - to store all active and timed out sessions --> more secure and powerful then asp's build in sessionmanagement
    - to also serve cookiedisabled users
    - to store the last page they requested --> i don't proces a form if this formpages value isn't the value in the db
    - to store the page they should be redirected to if they abort a proces or wan't to jump back a page --> i also don't require users to have javascript enabled and this enables me to make more stable applications.

  • #11
    Regular Coder
    Join Date
    Mar 2003
    Posts
    241
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Originally posted by whammy
    I agree... but using the HTTP_REFERER is a good way to make sure first of all that some wannabe hacker isn't creating his own HTML form to post to your website. Just check the ServerVariables collection and make sure you know where this post is coming from.
    On this point I have to disagree. I don't consider myself being a 'wannabe hacker', not even close but I know that the Server.Variables are basically useless when it comes to security; they are so easy to fake! Therefore they should not be relied on.
    Sessions / Cookies with encryption are much more secure. But this is kind of offtopic isnt it

    If using cookies is a problem, I'd perhaps provide a blurb on your website as to why cookies must be enabled.
    In sweden, there is some kind of law on that you _have to_ state that you use cookies, if you do. I'm not sure if the law say that you have to explicit state what they are used for. But maybe this is a Sweden-only-kind-of-thing, I don't know

    I think a session/cookie-check sounds exactly what Gary wants.
    Last edited by Caffeine; 10-15-2003 at 08:33 AM.

  • #12
    Regular Coder
    Join Date
    Oct 2003
    Location
    London, UK
    Posts
    411
    Thanks
    0
    Thanked 1 Time in 1 Post
    Originally posted by Caffeine
    On this point I have to disagree. I don't consider myself being a 'wannabe hacker', not even close but I know that the Server.Variables are basically useless when it comes to security; they are so easy to fake!
    Yes, anything originating from the client (HTTP headers in particular) is susceptible to manipulation.

    Never trust the client! lol
    Marcus Tucker / www / blog
    Web Analyst Programmer / Voted SPF "ASP Guru"

  • #13
    Regular Coder
    Join Date
    Mar 2003
    Posts
    176
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Maybe I've missed something fundamental (not uncommon ), but why explicitly check for (or set) a cookie if the requirement is only for a single session - as seems to be indicated in the original question?

    Why not just set a session variable and check that?

  • #14
    Regular Coder
    Join Date
    Mar 2003
    Posts
    241
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Originally posted by M@rco
    Yes, anything originating from the client (HTTP headers in particular) is susceptible to manipulation.

    Never trust the client! lol
    Call me paranoid.. but nope, never trust the clients if you want your webapp. to be secure!

  • #15
    raf
    raf is offline
    Master Coder
    Join Date
    Jul 2002
    Posts
    6,589
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Maybe I've missed something fundamental (not uncommon ), but why explicitly check for (or set) a cookie if the requirement is only for a single session - as seems to be indicated in the original question?
    because ASP sessions rely on cookies. So if the client has cookies disabled, a new ASP session is started for each requested ASP-page.
    The client side session cookie contains the sessionID, which the server needs to get with each request.

    More info:
    http://www.learnasp.com/learn/sessionswhat.asp

    The only way to check if the client has cookies enabled, is to write a cookie and then attempt to read it. (Well, it's the only way i know ...)


    There is also a PHP like way to deal with that problem (cookie disabled users) --> appending the sessionID to each URL but that is unsafe and shouldn't be used if you are concerned about session-hijacking. More info
    http://www.aspfaqs.com/webtech/TheBook/page5.asp
    Last edited by raf; 10-15-2003 at 10:24 AM.


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •