SV: Stoping someone from accessing a page directly


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 6 of 6

Thread: SV: Stoping someone from accessing a page directly

  1. #1
    Gunnar Syren Guest

    SV: Stoping someone from accessing a page directly

    In my opinion that's kind of like saying that Access is evil because it
    doesn't scale well. Pretty much anything can be "evil" if you use it without
    understanding it.

    Using hidden fields makes the code more complex and less easy to understand
    and maintain. In many cases that's a price you have to pay. But if you're
    developing a solution that you know will never be farmed (an intranet,
    perhaps) then using the Session Object is quite Ok in my book.

    The Session Object is not evil, ignorance is.

    /Gunnar

    Lior Amar <lior_amar@hotmail.com> skrev i
    diskussionsgruppsmeddelandet:395b9935@news.devx.com...
    > You're absolutely correct that the session object can be useful but my
    > cousin recently had hemorrhoids and that got him out of an exam...useful

    but
    > the price is too high. I just mentioned it and specifically pointed out
    > that this will be a problem if the system grows. On one machine it will
    > work but I've had to many companies that come see me cause they're in deep
    > trouble with the session object. A lot of programmers that come off

    Client
    > Server development are completely unaware of State Management for the web
    > and fall into the trap of using the SESSION OBJECT. I am just pointing

    out
    > that it takes 10 seconds more to use hidden fields in a form. I

    personally
    > utilize the database for my state management but hidden fields in forms

    will
    > do the job better then any SESSION object.
    >
    > But you're right the session object will work perfectly on a one machine
    > system that will never be expanded....it still doesn't change the fact

    that
    > it's evil.
    >
    > It's easier to learn good habits then unlearn bad habits!
    >
    >
    > --
    > Hope this Helps,
    >
    > Lee Amar
    > CTO OSTNet OpenSource Technologies
    > Advanced Computing Demands
    > Advanced Gaming Breaks
    > lior_amar@hotmail.com
    >
    > "Gunnar Syren" <gunnar.syren@datapoint.se> wrote in message
    > news:395b5333@news.devx.com...
    > > Lior,
    > > Isn't this generalising things a bit? The KB article you point to refers

    > to
    > > "Web Farms".
    > > This would be normal if you're in e-business, but there is nothing (as

    far
    > > as I could see)
    > > in the original question that indicates that this is about e-business

    (or
    > > any other kind
    > > of Web Farm).
    > >
    > > Session objects can be quite useful if you understand their limitations.
    > >
    > > /Gunnar
    > >
    > > Lior Amar <lior_amar@hotmail.com> skrev i
    > > diskussionsgruppsmeddelandet:395a20ff$1@news.devx.com...
    > > >
    > > > OOh man...Session objects are evil...just have a parm that you pass

    from
    > > one
    > > > form to another or be more advanced and have values stored in a

    database
    > > > that you check. This code will work no problem but Session objects

    are
    > > > evil. Assume your user logged in and should have access to that form

    > but
    > > he
    > > > logged in on ServerA. He now clicks on a button on that form and goes

    > to
    > > > ServerC, will this code work? No because the client session info is

    on
    > > > ServerA. The only way this will work is if you have a load balancer

    > that
    > > > permits for "Sticky Sessions" (affinity) which in itself is EVIL.

    > Take
    > > a
    > > > look at this little document, I mean even microsoft doesn't recommend

    > > using
    > > > the Session object.
    > > >
    > > > http://support.microsoft.com/support.../Q258/6/99.ASP
    > > >
    > > > Although once again Devins message is 100% correct cause it will

    > work...I
    > > > still though you might want a second opinion. Remeber, the Web

    business
    > > has
    > > > proven that the dumbest ideas in the world can make money on the net

    > which
    > > > means a small program that was ment to only work on one machine can
    > > > overnight need to be placed on a webfarm.
    > > >
    > > > Once again, SESSION = EVIL
    > > >
    > > > Just my two cents,
    > > >
    > > > --
    > > > Hope this Helps,
    > > >
    > > > Lee Amar
    > > > CTO OSTNet OpenSource Technologies
    > > > Advanced Computing Demands
    > > > Advanced Gaming Breaks
    > > > lior_amar@hotmail.com
    > > >
    > > >
    > > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote in message
    > > > news:3953be1f$1@news.devx.com...
    > > > > OK. The easiest way to do this is by setting a simple Session
    > > > > Variable. From your login page, once you have determined that the
    > > > > login is valid set something like:
    > > > > Session("blnGoodUser") = True
    > > > >
    > > > > Then at the top of each page to be protected, check this flag, and
    > > > > if it is not present, redirect the browser to the login page:
    > > > >
    > > > > If Not Session("blnGoodUser") Then
    > > > > Response.Clear
    > > > > Response.Redirect("login.asp")
    > > > > Response.End
    > > > > End If
    > > > >
    > > > > Hope This Helps!
    > > > >
    > > > > --
    > > > >
    > > > > -Devin
    > > > > ______________________________________________
    > > > > Get on your feet and do the Funky Alphonso!
    > > > >
    > > > >
    > > > >
    > > > > "portly" <portly@coolemail.com> wrote in message
    > > > > news:3953aaec@news.devx.com...
    > > > > >
    > > > > > I want to have it so you must enter though another page to view
    > > > > the new page.
    > > > > >
    > > > > > I have online forms that I want to keep from being directly
    > > > > accessed. They
    > > > > > must go throught a client login first.
    > > > > >
    > > > > >
    > > > > > Portly
    > > > > >
    > > > > >
    > > > > >
    > > > > >
    > > > > >
    > > > > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote:
    > > > > > >I'm not quite clear on you question. Do you want to block
    > > > > > >everyone from viewing a specific page(es), or are you wanting
    > > > > to
    > > > > > >block a specific user(s) from viewing anything?
    > > > > > >
    > > > > > >--
    > > > > > >
    > > > > > > -Devin
    > > > > > > ______________________________________________
    > > > > > > Get on your feet and do the Funky Alphonso!
    > > > > > >
    > > > > > >
    > > > > > >
    > > > > > >"Portly" <portly@coolemail.com> wrote in message
    > > > > > >news:3953a3f5$1@news.devx.com...
    > > > > > >>
    > > > > > >> Does anyone know to eliminate a user from accessing a page by
    > > > > > >just putting
    > > > > > >> in the address? I know that can be eliminated by script code
    > > > > > >but how???
    > > > > > >>
    > > > > > >>
    > > > > > >> thanks in advance
    > > > > > >>
    > > > > > >> Portly
    > > > > > >
    > > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >




  2. #2
    Al Guest

    Re: SV: Stoping someone from accessing a page directly


    Session is bad. Part of my job is rewriting the "little" apps that someone
    coded with session - they invariable grew into big apps that could not scale.
    It's just bad practice.

    desktop programmers trying to switch over are addicted to session. The world
    is not client/server anymore.

    The simplest way to keep users from dropping in on any page is to create
    a routine that checks at the top of each page where the browser came from.
    This information is stored in the headers - unless you are on an intranet
    and the browser is coming through a proxy.. in which case you will have the
    proxy address - which is useless. However you can utilize server variables
    ("scriptname") to do the same thing.

    Al


    "Gunnar Syren" <gunnar.syren@datapoint.se> wrote:
    >In my opinion that's kind of like saying that Access is evil because it
    >doesn't scale well. Pretty much anything can be "evil" if you use it without
    >understanding it.
    >
    >Using hidden fields makes the code more complex and less easy to understand
    >and maintain. In many cases that's a price you have to pay. But if you're
    >developing a solution that you know will never be farmed (an intranet,
    >perhaps) then using the Session Object is quite Ok in my book.
    >
    >The Session Object is not evil, ignorance is.
    >
    >/Gunnar
    >
    >Lior Amar <lior_amar@hotmail.com> skrev i
    >diskussionsgruppsmeddelandet:395b9935@news.devx.com...
    >> You're absolutely correct that the session object can be useful but my
    >> cousin recently had hemorrhoids and that got him out of an exam...useful

    >but
    >> the price is too high. I just mentioned it and specifically pointed out
    >> that this will be a problem if the system grows. On one machine it will
    >> work but I've had to many companies that come see me cause they're in

    deep
    >> trouble with the session object. A lot of programmers that come off

    >Client
    >> Server development are completely unaware of State Management for the

    web
    >> and fall into the trap of using the SESSION OBJECT. I am just pointing

    >out
    >> that it takes 10 seconds more to use hidden fields in a form. I

    >personally
    >> utilize the database for my state management but hidden fields in forms

    >will
    >> do the job better then any SESSION object.
    >>
    >> But you're right the session object will work perfectly on a one machine
    >> system that will never be expanded....it still doesn't change the fact

    >that
    >> it's evil.
    >>
    >> It's easier to learn good habits then unlearn bad habits!
    >>
    >>
    >> --
    >> Hope this Helps,
    >>
    >> Lee Amar
    >> CTO OSTNet OpenSource Technologies
    >> Advanced Computing Demands
    >> Advanced Gaming Breaks
    >> lior_amar@hotmail.com
    >>
    >> "Gunnar Syren" <gunnar.syren@datapoint.se> wrote in message
    >> news:395b5333@news.devx.com...
    >> > Lior,
    >> > Isn't this generalising things a bit? The KB article you point to refers

    >> to
    >> > "Web Farms".
    >> > This would be normal if you're in e-business, but there is nothing (as

    >far
    >> > as I could see)
    >> > in the original question that indicates that this is about e-business

    >(or
    >> > any other kind
    >> > of Web Farm).
    >> >
    >> > Session objects can be quite useful if you understand their limitations.
    >> >
    >> > /Gunnar
    >> >
    >> > Lior Amar <lior_amar@hotmail.com> skrev i
    >> > diskussionsgruppsmeddelandet:395a20ff$1@news.devx.com...
    >> > >
    >> > > OOh man...Session objects are evil...just have a parm that you pass

    >from
    >> > one
    >> > > form to another or be more advanced and have values stored in a

    >database
    >> > > that you check. This code will work no problem but Session objects

    >are
    >> > > evil. Assume your user logged in and should have access to that form

    >> but
    >> > he
    >> > > logged in on ServerA. He now clicks on a button on that form and

    goes
    >> to
    >> > > ServerC, will this code work? No because the client session info

    is
    >on
    >> > > ServerA. The only way this will work is if you have a load balancer

    >> that
    >> > > permits for "Sticky Sessions" (affinity) which in itself is EVIL.

    >> Take
    >> > a
    >> > > look at this little document, I mean even microsoft doesn't recommend
    >> > using
    >> > > the Session object.
    >> > >
    >> > > http://support.microsoft.com/support.../Q258/6/99.ASP
    >> > >
    >> > > Although once again Devins message is 100% correct cause it will

    >> work...I
    >> > > still though you might want a second opinion. Remeber, the Web

    >business
    >> > has
    >> > > proven that the dumbest ideas in the world can make money on the net

    >> which
    >> > > means a small program that was ment to only work on one machine can
    >> > > overnight need to be placed on a webfarm.
    >> > >
    >> > > Once again, SESSION = EVIL
    >> > >
    >> > > Just my two cents,
    >> > >
    >> > > --
    >> > > Hope this Helps,
    >> > >
    >> > > Lee Amar
    >> > > CTO OSTNet OpenSource Technologies
    >> > > Advanced Computing Demands
    >> > > Advanced Gaming Breaks
    >> > > lior_amar@hotmail.com
    >> > >
    >> > >
    >> > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote in message
    >> > > news:3953be1f$1@news.devx.com...
    >> > > > OK. The easiest way to do this is by setting a simple Session
    >> > > > Variable. From your login page, once you have determined that the
    >> > > > login is valid set something like:
    >> > > > Session("blnGoodUser") = True
    >> > > >
    >> > > > Then at the top of each page to be protected, check this flag, and
    >> > > > if it is not present, redirect the browser to the login page:
    >> > > >
    >> > > > If Not Session("blnGoodUser") Then
    >> > > > Response.Clear
    >> > > > Response.Redirect("login.asp")
    >> > > > Response.End
    >> > > > End If
    >> > > >
    >> > > > Hope This Helps!
    >> > > >
    >> > > > --
    >> > > >
    >> > > > -Devin
    >> > > > ______________________________________________
    >> > > > Get on your feet and do the Funky Alphonso!
    >> > > >
    >> > > >
    >> > > >
    >> > > > "portly" <portly@coolemail.com> wrote in message
    >> > > > news:3953aaec@news.devx.com...
    >> > > > >
    >> > > > > I want to have it so you must enter though another page to view
    >> > > > the new page.
    >> > > > >
    >> > > > > I have online forms that I want to keep from being directly
    >> > > > accessed. They
    >> > > > > must go throught a client login first.
    >> > > > >
    >> > > > >
    >> > > > > Portly
    >> > > > >
    >> > > > >
    >> > > > >
    >> > > > >
    >> > > > >
    >> > > > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote:
    >> > > > > >I'm not quite clear on you question. Do you want to block
    >> > > > > >everyone from viewing a specific page(es), or are you wanting
    >> > > > to
    >> > > > > >block a specific user(s) from viewing anything?
    >> > > > > >
    >> > > > > >--
    >> > > > > >
    >> > > > > > -Devin
    >> > > > > > ______________________________________________
    >> > > > > > Get on your feet and do the Funky Alphonso!
    >> > > > > >
    >> > > > > >
    >> > > > > >
    >> > > > > >"Portly" <portly@coolemail.com> wrote in message
    >> > > > > >news:3953a3f5$1@news.devx.com...
    >> > > > > >>
    >> > > > > >> Does anyone know to eliminate a user from accessing a page

    by
    >> > > > > >just putting
    >> > > > > >> in the address? I know that can be eliminated by script code
    >> > > > > >but how???
    >> > > > > >>
    >> > > > > >>
    >> > > > > >> thanks in advance
    >> > > > > >>
    >> > > > > >> Portly
    >> > > > > >
    >> > > > > >
    >> > > > >
    >> > > >
    >> > > >
    >> > >
    >> > >
    >> >
    >> >

    >>
    >>

    >
    >



  3. #3
    Steve Guest

    Re: SV: Stoping someone from accessing a page directly


    1. Session is bad only if you want to use a web farm
    2. Hidden values on a form could be insecure depending on your implementation.
    What you want to store is a key to a logical session whose data you store
    in the database.
    You DO NOT want to store Authenticated=True or anything like that. Remember
    a user could View source, save to file, change data and resubmit the form.
    Not all pages are posted, which makes the hidden form field technique more
    troublesome to deal with. Some other environments (than ASP) encourage you
    to embed your session reference in every URL.
    At any rate, since you need to handle generation of a session id and manage
    its timeout yourself if you eschew ASP's session, then you have work on your
    hands to get something near as equivalent.

    NOTE: I have seen third party session management objects which store their
    state on a common file system to enable web form use. MS also provides similar
    capability using Site Server (articles are in MSDN not too long ago).

    3. The HTTP_REFERRER technique is interesting. I hadn't seen that before.
    The only thing that makes that tricky is that you will likely have a mix
    of unsecured and secured pages, thus you would need to check that the referred
    page was a secured page. Perhaps you would put all secured pages into /secure/mypage.asp
    so you could check the referred for "/secure/" to make it easier to code.
    As an aside, I don't think this technique is truely secure, since I could
    handcraft an HTTP request header and make it look like I came form a secured
    page.

    All in all, I would just use Session and migrate to a web form friendly session
    replacement later when I got big enough to need Web Farm scalability.

    -Steve

    "Al" <buddha@zenmaster.com> wrote:
    >
    >Session is bad. Part of my job is rewriting the "little" apps that someone
    >coded with session - they invariable grew into big apps that could not scale.
    >It's just bad practice.
    >
    >desktop programmers trying to switch over are addicted to session. The world
    >is not client/server anymore.
    >
    >The simplest way to keep users from dropping in on any page is to create
    >a routine that checks at the top of each page where the browser came from.
    >This information is stored in the headers - unless you are on an intranet
    >and the browser is coming through a proxy.. in which case you will have

    the
    >proxy address - which is useless. However you can utilize server variables
    >("scriptname") to do the same thing.
    >
    >Al
    >
    >
    >"Gunnar Syren" <gunnar.syren@datapoint.se> wrote:
    >>In my opinion that's kind of like saying that Access is evil because it
    >>doesn't scale well. Pretty much anything can be "evil" if you use it without
    >>understanding it.
    >>
    >>Using hidden fields makes the code more complex and less easy to understand
    >>and maintain. In many cases that's a price you have to pay. But if you're
    >>developing a solution that you know will never be farmed (an intranet,
    >>perhaps) then using the Session Object is quite Ok in my book.
    >>
    >>The Session Object is not evil, ignorance is.
    >>
    >>/Gunnar
    >>
    >>Lior Amar <lior_amar@hotmail.com> skrev i
    >>diskussionsgruppsmeddelandet:395b9935@news.devx.com...
    >>> You're absolutely correct that the session object can be useful but my
    >>> cousin recently had hemorrhoids and that got him out of an exam...useful

    >>but
    >>> the price is too high. I just mentioned it and specifically pointed

    out
    >>> that this will be a problem if the system grows. On one machine it will
    >>> work but I've had to many companies that come see me cause they're in

    >deep
    >>> trouble with the session object. A lot of programmers that come off

    >>Client
    >>> Server development are completely unaware of State Management for the

    >web
    >>> and fall into the trap of using the SESSION OBJECT. I am just pointing

    >>out
    >>> that it takes 10 seconds more to use hidden fields in a form. I

    >>personally
    >>> utilize the database for my state management but hidden fields in forms

    >>will
    >>> do the job better then any SESSION object.
    >>>
    >>> But you're right the session object will work perfectly on a one machine
    >>> system that will never be expanded....it still doesn't change the fact

    >>that
    >>> it's evil.
    >>>
    >>> It's easier to learn good habits then unlearn bad habits!
    >>>
    >>>
    >>> --
    >>> Hope this Helps,
    >>>
    >>> Lee Amar
    >>> CTO OSTNet OpenSource Technologies
    >>> Advanced Computing Demands
    >>> Advanced Gaming Breaks
    >>> lior_amar@hotmail.com
    >>>
    >>> "Gunnar Syren" <gunnar.syren@datapoint.se> wrote in message
    >>> news:395b5333@news.devx.com...
    >>> > Lior,
    >>> > Isn't this generalising things a bit? The KB article you point to refers
    >>> to
    >>> > "Web Farms".
    >>> > This would be normal if you're in e-business, but there is nothing

    (as
    >>far
    >>> > as I could see)
    >>> > in the original question that indicates that this is about e-business

    >>(or
    >>> > any other kind
    >>> > of Web Farm).
    >>> >
    >>> > Session objects can be quite useful if you understand their limitations.
    >>> >
    >>> > /Gunnar
    >>> >
    >>> > Lior Amar <lior_amar@hotmail.com> skrev i
    >>> > diskussionsgruppsmeddelandet:395a20ff$1@news.devx.com...
    >>> > >
    >>> > > OOh man...Session objects are evil...just have a parm that you pass

    >>from
    >>> > one
    >>> > > form to another or be more advanced and have values stored in a

    >>database
    >>> > > that you check. This code will work no problem but Session objects

    >>are
    >>> > > evil. Assume your user logged in and should have access to that

    form
    >>> but
    >>> > he
    >>> > > logged in on ServerA. He now clicks on a button on that form and

    >goes
    >>> to
    >>> > > ServerC, will this code work? No because the client session info

    >is
    >>on
    >>> > > ServerA. The only way this will work is if you have a load balancer
    >>> that
    >>> > > permits for "Sticky Sessions" (affinity) which in itself is EVIL.
    >>> Take
    >>> > a
    >>> > > look at this little document, I mean even microsoft doesn't recommend
    >>> > using
    >>> > > the Session object.
    >>> > >
    >>> > > http://support.microsoft.com/support.../Q258/6/99.ASP
    >>> > >
    >>> > > Although once again Devins message is 100% correct cause it will
    >>> work...I
    >>> > > still though you might want a second opinion. Remeber, the Web

    >>business
    >>> > has
    >>> > > proven that the dumbest ideas in the world can make money on the

    net
    >>> which
    >>> > > means a small program that was ment to only work on one machine can
    >>> > > overnight need to be placed on a webfarm.
    >>> > >
    >>> > > Once again, SESSION = EVIL
    >>> > >
    >>> > > Just my two cents,
    >>> > >
    >>> > > --
    >>> > > Hope this Helps,
    >>> > >
    >>> > > Lee Amar
    >>> > > CTO OSTNet OpenSource Technologies
    >>> > > Advanced Computing Demands
    >>> > > Advanced Gaming Breaks
    >>> > > lior_amar@hotmail.com
    >>> > >
    >>> > >
    >>> > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote in message
    >>> > > news:3953be1f$1@news.devx.com...
    >>> > > > OK. The easiest way to do this is by setting a simple Session
    >>> > > > Variable. From your login page, once you have determined that

    the
    >>> > > > login is valid set something like:
    >>> > > > Session("blnGoodUser") = True
    >>> > > >
    >>> > > > Then at the top of each page to be protected, check this flag,

    and
    >>> > > > if it is not present, redirect the browser to the login page:
    >>> > > >
    >>> > > > If Not Session("blnGoodUser") Then
    >>> > > > Response.Clear
    >>> > > > Response.Redirect("login.asp")
    >>> > > > Response.End
    >>> > > > End If
    >>> > > >
    >>> > > > Hope This Helps!
    >>> > > >
    >>> > > > --
    >>> > > >
    >>> > > > -Devin
    >>> > > > ______________________________________________
    >>> > > > Get on your feet and do the Funky Alphonso!
    >>> > > >
    >>> > > >
    >>> > > >
    >>> > > > "portly" <portly@coolemail.com> wrote in message
    >>> > > > news:3953aaec@news.devx.com...
    >>> > > > >
    >>> > > > > I want to have it so you must enter though another page to view
    >>> > > > the new page.
    >>> > > > >
    >>> > > > > I have online forms that I want to keep from being directly
    >>> > > > accessed. They
    >>> > > > > must go throught a client login first.
    >>> > > > >
    >>> > > > >
    >>> > > > > Portly
    >>> > > > >
    >>> > > > >
    >>> > > > >
    >>> > > > >
    >>> > > > >
    >>> > > > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote:
    >>> > > > > >I'm not quite clear on you question. Do you want to block
    >>> > > > > >everyone from viewing a specific page(es), or are you wanting
    >>> > > > to
    >>> > > > > >block a specific user(s) from viewing anything?
    >>> > > > > >
    >>> > > > > >--
    >>> > > > > >
    >>> > > > > > -Devin
    >>> > > > > > ______________________________________________
    >>> > > > > > Get on your feet and do the Funky Alphonso!
    >>> > > > > >
    >>> > > > > >
    >>> > > > > >
    >>> > > > > >"Portly" <portly@coolemail.com> wrote in message
    >>> > > > > >news:3953a3f5$1@news.devx.com...
    >>> > > > > >>
    >>> > > > > >> Does anyone know to eliminate a user from accessing a page

    >by
    >>> > > > > >just putting
    >>> > > > > >> in the address? I know that can be eliminated by script code
    >>> > > > > >but how???
    >>> > > > > >>
    >>> > > > > >>
    >>> > > > > >> thanks in advance
    >>> > > > > >>
    >>> > > > > >> Portly
    >>> > > > > >
    >>> > > > > >
    >>> > > > >
    >>> > > >
    >>> > > >
    >>> > >
    >>> > >
    >>> >
    >>> >
    >>>
    >>>

    >>
    >>

    >



  4. #4
    Lior Amar Guest

    Re: Stoping someone from accessing a page directly

    You know your last sentence is exactly the truth, ignorance is evil...It so
    happens that most people that use the Session object is because they don't
    know any better. Not knowing any better doesn't mean it's the right way of
    doing it. The Session object is not the right way of doing things plain and
    simple. I don't care how small an application is initially if you take the
    time to analyze your implementation you will come to understand that not
    using the session object is about 5 minutes more work. The session object
    is for people who are stuck with the concept of state and have yet to figure
    out how to better handle state in a stateless environment. I will always
    stand by my guns in saying the session object is simply bad implementation
    and programmers that use it today will pay the price tomorrow. You know
    what makes me laugh, is that I was recently at a Microsoft convention and
    was talking to one of the presenters and we were talking about exactly this
    subject. Needless to say he sees it my way...all developers who have done
    big apps and had to come to terms with state management tend to see the
    session object in that way. But once again, you're 100% correct in saying
    the session object is a valid way to store variables for small app....still
    doesn't make it the right way!

    But that's cool, to each his own. All I was saying is their are better ways
    of handling variables then session object and like somebody else said....use
    the database it's the best way of them all.


    --
    Hope this Helps,

    Lee Amar
    CTO OSTNet OpenSource Technologies
    Advanced Computing Demands
    Advanced Gaming Breaks
    lior@ostnet.com


    "Gunnar Syren" <gunnar.syren@datapoint.se> wrote in message
    news:395c4b21@news.devx.com...
    > In my opinion that's kind of like saying that Access is evil because it
    > doesn't scale well. Pretty much anything can be "evil" if you use it

    without
    > understanding it.
    >
    > Using hidden fields makes the code more complex and less easy to

    understand
    > and maintain. In many cases that's a price you have to pay. But if you're
    > developing a solution that you know will never be farmed (an intranet,
    > perhaps) then using the Session Object is quite Ok in my book.
    >
    > The Session Object is not evil, ignorance is.
    >
    > /Gunnar
    >
    > Lior Amar <lior_amar@hotmail.com> skrev i
    > diskussionsgruppsmeddelandet:395b9935@news.devx.com...
    > > You're absolutely correct that the session object can be useful but my
    > > cousin recently had hemorrhoids and that got him out of an exam...useful

    > but
    > > the price is too high. I just mentioned it and specifically pointed out
    > > that this will be a problem if the system grows. On one machine it will
    > > work but I've had to many companies that come see me cause they're in

    deep
    > > trouble with the session object. A lot of programmers that come off

    > Client
    > > Server development are completely unaware of State Management for the

    web
    > > and fall into the trap of using the SESSION OBJECT. I am just pointing

    > out
    > > that it takes 10 seconds more to use hidden fields in a form. I

    > personally
    > > utilize the database for my state management but hidden fields in forms

    > will
    > > do the job better then any SESSION object.
    > >
    > > But you're right the session object will work perfectly on a one machine
    > > system that will never be expanded....it still doesn't change the fact

    > that
    > > it's evil.
    > >
    > > It's easier to learn good habits then unlearn bad habits!
    > >
    > >
    > > --
    > > Hope this Helps,
    > >
    > > Lee Amar
    > > CTO OSTNet OpenSource Technologies
    > > Advanced Computing Demands
    > > Advanced Gaming Breaks
    > > lior_amar@hotmail.com
    > >
    > > "Gunnar Syren" <gunnar.syren@datapoint.se> wrote in message
    > > news:395b5333@news.devx.com...
    > > > Lior,
    > > > Isn't this generalising things a bit? The KB article you point to

    refers
    > > to
    > > > "Web Farms".
    > > > This would be normal if you're in e-business, but there is nothing (as

    > far
    > > > as I could see)
    > > > in the original question that indicates that this is about e-business

    > (or
    > > > any other kind
    > > > of Web Farm).
    > > >
    > > > Session objects can be quite useful if you understand their

    limitations.
    > > >
    > > > /Gunnar
    > > >
    > > > Lior Amar <lior_amar@hotmail.com> skrev i
    > > > diskussionsgruppsmeddelandet:395a20ff$1@news.devx.com...
    > > > >
    > > > > OOh man...Session objects are evil...just have a parm that you pass

    > from
    > > > one
    > > > > form to another or be more advanced and have values stored in a

    > database
    > > > > that you check. This code will work no problem but Session objects

    > are
    > > > > evil. Assume your user logged in and should have access to that

    form
    > > but
    > > > he
    > > > > logged in on ServerA. He now clicks on a button on that form and

    goes
    > > to
    > > > > ServerC, will this code work? No because the client session info is

    > on
    > > > > ServerA. The only way this will work is if you have a load balancer

    > > that
    > > > > permits for "Sticky Sessions" (affinity) which in itself is EVIL.

    > > Take
    > > > a
    > > > > look at this little document, I mean even microsoft doesn't

    recommend
    > > > using
    > > > > the Session object.
    > > > >
    > > > > http://support.microsoft.com/support.../Q258/6/99.ASP
    > > > >
    > > > > Although once again Devins message is 100% correct cause it will

    > > work...I
    > > > > still though you might want a second opinion. Remeber, the Web

    > business
    > > > has
    > > > > proven that the dumbest ideas in the world can make money on the net

    > > which
    > > > > means a small program that was ment to only work on one machine can
    > > > > overnight need to be placed on a webfarm.
    > > > >
    > > > > Once again, SESSION = EVIL
    > > > >
    > > > > Just my two cents,
    > > > >
    > > > > --
    > > > > Hope this Helps,
    > > > >
    > > > > Lee Amar
    > > > > CTO OSTNet OpenSource Technologies
    > > > > Advanced Computing Demands
    > > > > Advanced Gaming Breaks
    > > > > lior_amar@hotmail.com
    > > > >
    > > > >
    > > > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote in message
    > > > > news:3953be1f$1@news.devx.com...
    > > > > > OK. The easiest way to do this is by setting a simple Session
    > > > > > Variable. From your login page, once you have determined that the
    > > > > > login is valid set something like:
    > > > > > Session("blnGoodUser") = True
    > > > > >
    > > > > > Then at the top of each page to be protected, check this flag, and
    > > > > > if it is not present, redirect the browser to the login page:
    > > > > >
    > > > > > If Not Session("blnGoodUser") Then
    > > > > > Response.Clear
    > > > > > Response.Redirect("login.asp")
    > > > > > Response.End
    > > > > > End If
    > > > > >
    > > > > > Hope This Helps!
    > > > > >
    > > > > > --
    > > > > >
    > > > > > -Devin
    > > > > > ______________________________________________
    > > > > > Get on your feet and do the Funky Alphonso!
    > > > > >
    > > > > >
    > > > > >
    > > > > > "portly" <portly@coolemail.com> wrote in message
    > > > > > news:3953aaec@news.devx.com...
    > > > > > >
    > > > > > > I want to have it so you must enter though another page to view
    > > > > > the new page.
    > > > > > >
    > > > > > > I have online forms that I want to keep from being directly
    > > > > > accessed. They
    > > > > > > must go throught a client login first.
    > > > > > >
    > > > > > >
    > > > > > > Portly
    > > > > > >
    > > > > > >
    > > > > > >
    > > > > > >
    > > > > > >
    > > > > > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote:
    > > > > > > >I'm not quite clear on you question. Do you want to block
    > > > > > > >everyone from viewing a specific page(es), or are you wanting
    > > > > > to
    > > > > > > >block a specific user(s) from viewing anything?
    > > > > > > >
    > > > > > > >--
    > > > > > > >
    > > > > > > > -Devin
    > > > > > > > ______________________________________________
    > > > > > > > Get on your feet and do the Funky Alphonso!
    > > > > > > >
    > > > > > > >
    > > > > > > >
    > > > > > > >"Portly" <portly@coolemail.com> wrote in message
    > > > > > > >news:3953a3f5$1@news.devx.com...
    > > > > > > >>
    > > > > > > >> Does anyone know to eliminate a user from accessing a page by
    > > > > > > >just putting
    > > > > > > >> in the address? I know that can be eliminated by script code
    > > > > > > >but how???
    > > > > > > >>
    > > > > > > >>
    > > > > > > >> thanks in advance
    > > > > > > >>
    > > > > > > >> Portly
    > > > > > > >
    > > > > > > >
    > > > > > >
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >




  5. #5
    Matt Hodge Guest

    Re: Stoping someone from accessing a page directly

    We have this discussion about Session variables in my office all the time.
    A lot of the developers here tend to agree with you ... NEVER use a Session
    variable. In my opinion they are not always evil. There are times to use
    the Session variables and times not to. I use two different methods in
    using the Session variables.

    The first is to create include files with smaller functions that save and
    read the Session variables. This ensures that IF I do need to change it
    from a "smaller app" to something like a web-farm then I just have to change
    those smaller functions to access a database. One of the benefits of always
    abstracting to functions in every part of your app ... it is always easier
    to make any type of changes.

    The more common method I use is kinda similiar. I typically still write the
    include files with funtions to retrieve values. However in those functions
    the first thing I do is check the Session variable. If I find a valid value
    then I keep moving on ... however if not then I go to the database. To me
    this improves performance as I do not HAVE to go to the database each time,
    but it protects me for web-farm situations.

    Just my 2 cents.

    Matt Hodge


    "Lior Amar" <lior_amar@hotmail.com> wrote in message
    news:395cd07c@news.devx.com...
    > You know your last sentence is exactly the truth, ignorance is evil...It

    so
    > happens that most people that use the Session object is because they don't
    > know any better. Not knowing any better doesn't mean it's the right way

    of
    > doing it. The Session object is not the right way of doing things plain

    and
    > simple. I don't care how small an application is initially if you take

    the
    > time to analyze your implementation you will come to understand that not
    > using the session object is about 5 minutes more work. The session object
    > is for people who are stuck with the concept of state and have yet to

    figure
    > out how to better handle state in a stateless environment. I will always
    > stand by my guns in saying the session object is simply bad implementation
    > and programmers that use it today will pay the price tomorrow. You know
    > what makes me laugh, is that I was recently at a Microsoft convention and
    > was talking to one of the presenters and we were talking about exactly

    this
    > subject. Needless to say he sees it my way...all developers who have done
    > big apps and had to come to terms with state management tend to see the
    > session object in that way. But once again, you're 100% correct in saying
    > the session object is a valid way to store variables for small

    app....still
    > doesn't make it the right way!
    >
    > But that's cool, to each his own. All I was saying is their are better

    ways
    > of handling variables then session object and like somebody else

    said....use
    > the database it's the best way of them all.
    >
    >
    > --
    > Hope this Helps,
    >
    > Lee Amar
    > CTO OSTNet OpenSource Technologies
    > Advanced Computing Demands
    > Advanced Gaming Breaks
    > lior@ostnet.com
    >





  6. #6
    stephie Guest

    Re: SV: Stoping someone from accessing a page directly


    Hi! I am having trouble finding an html script I can use to block a particular
    domain or ip number from my private web site.
    I would prefer not to get my server involved. I am not in your leagues, just
    a basic web design addict.
    Thanks, Stephie


    "Steve" <nospamme.sderochemont@mindspring.com> wrote:
    >
    >1. Session is bad only if you want to use a web farm
    >2. Hidden values on a form could be insecure depending on your implementation.
    >What you want to store is a key to a logical session whose data you store
    >in the database.
    >You DO NOT want to store Authenticated=True or anything like that. Remember
    >a user could View source, save to file, change data and resubmit the form.
    >Not all pages are posted, which makes the hidden form field technique more
    >troublesome to deal with. Some other environments (than ASP) encourage you
    >to embed your session reference in every URL.
    >At any rate, since you need to handle generation of a session id and manage
    >its timeout yourself if you eschew ASP's session, then you have work on

    your
    >hands to get something near as equivalent.
    >
    >NOTE: I have seen third party session management objects which store their
    >state on a common file system to enable web form use. MS also provides similar
    >capability using Site Server (articles are in MSDN not too long ago).
    >
    >3. The HTTP_REFERRER technique is interesting. I hadn't seen that before.
    >The only thing that makes that tricky is that you will likely have a mix
    >of unsecured and secured pages, thus you would need to check that the referred
    >page was a secured page. Perhaps you would put all secured pages into /secure/mypage.asp
    >so you could check the referred for "/secure/" to make it easier to code.
    >As an aside, I don't think this technique is truely secure, since I could
    >handcraft an HTTP request header and make it look like I came form a secured
    >page.
    >
    >All in all, I would just use Session and migrate to a web form friendly

    session
    >replacement later when I got big enough to need Web Farm scalability.
    >
    >-Steve
    >
    >"Al" <buddha@zenmaster.com> wrote:
    >>
    >>Session is bad. Part of my job is rewriting the "little" apps that someone
    >>coded with session - they invariable grew into big apps that could not

    scale.
    >>It's just bad practice.
    >>
    >>desktop programmers trying to switch over are addicted to session. The

    world
    >>is not client/server anymore.
    >>
    >>The simplest way to keep users from dropping in on any page is to create
    >>a routine that checks at the top of each page where the browser came from.
    >>This information is stored in the headers - unless you are on an intranet
    >>and the browser is coming through a proxy.. in which case you will have

    >the
    >>proxy address - which is useless. However you can utilize server variables
    >>("scriptname") to do the same thing.
    >>
    >>Al
    >>
    >>
    >>"Gunnar Syren" <gunnar.syren@datapoint.se> wrote:
    >>>In my opinion that's kind of like saying that Access is evil because it
    >>>doesn't scale well. Pretty much anything can be "evil" if you use it without
    >>>understanding it.
    >>>
    >>>Using hidden fields makes the code more complex and less easy to understand
    >>>and maintain. In many cases that's a price you have to pay. But if you're
    >>>developing a solution that you know will never be farmed (an intranet,
    >>>perhaps) then using the Session Object is quite Ok in my book.
    >>>
    >>>The Session Object is not evil, ignorance is.
    >>>
    >>>/Gunnar
    >>>
    >>>Lior Amar <lior_amar@hotmail.com> skrev i
    >>>diskussionsgruppsmeddelandet:395b9935@news.devx.com...
    >>>> You're absolutely correct that the session object can be useful but

    my
    >>>> cousin recently had hemorrhoids and that got him out of an exam...useful
    >>>but
    >>>> the price is too high. I just mentioned it and specifically pointed

    >out
    >>>> that this will be a problem if the system grows. On one machine it

    will
    >>>> work but I've had to many companies that come see me cause they're in

    >>deep
    >>>> trouble with the session object. A lot of programmers that come off
    >>>Client
    >>>> Server development are completely unaware of State Management for the

    >>web
    >>>> and fall into the trap of using the SESSION OBJECT. I am just pointing
    >>>out
    >>>> that it takes 10 seconds more to use hidden fields in a form. I
    >>>personally
    >>>> utilize the database for my state management but hidden fields in forms
    >>>will
    >>>> do the job better then any SESSION object.
    >>>>
    >>>> But you're right the session object will work perfectly on a one machine
    >>>> system that will never be expanded....it still doesn't change the fact
    >>>that
    >>>> it's evil.
    >>>>
    >>>> It's easier to learn good habits then unlearn bad habits!
    >>>>
    >>>>
    >>>> --
    >>>> Hope this Helps,
    >>>>
    >>>> Lee Amar
    >>>> CTO OSTNet OpenSource Technologies
    >>>> Advanced Computing Demands
    >>>> Advanced Gaming Breaks
    >>>> lior_amar@hotmail.com
    >>>>
    >>>> "Gunnar Syren" <gunnar.syren@datapoint.se> wrote in message
    >>>> news:395b5333@news.devx.com...
    >>>> > Lior,
    >>>> > Isn't this generalising things a bit? The KB article you point to

    refers
    >>>> to
    >>>> > "Web Farms".
    >>>> > This would be normal if you're in e-business, but there is nothing

    >(as
    >>>far
    >>>> > as I could see)
    >>>> > in the original question that indicates that this is about e-business
    >>>(or
    >>>> > any other kind
    >>>> > of Web Farm).
    >>>> >
    >>>> > Session objects can be quite useful if you understand their limitations.
    >>>> >
    >>>> > /Gunnar
    >>>> >
    >>>> > Lior Amar <lior_amar@hotmail.com> skrev i
    >>>> > diskussionsgruppsmeddelandet:395a20ff$1@news.devx.com...
    >>>> > >
    >>>> > > OOh man...Session objects are evil...just have a parm that you pass
    >>>from
    >>>> > one
    >>>> > > form to another or be more advanced and have values stored in a
    >>>database
    >>>> > > that you check. This code will work no problem but Session objects
    >>>are
    >>>> > > evil. Assume your user logged in and should have access to that

    >form
    >>>> but
    >>>> > he
    >>>> > > logged in on ServerA. He now clicks on a button on that form and

    >>goes
    >>>> to
    >>>> > > ServerC, will this code work? No because the client session info

    >>is
    >>>on
    >>>> > > ServerA. The only way this will work is if you have a load balancer
    >>>> that
    >>>> > > permits for "Sticky Sessions" (affinity) which in itself is EVIL.
    >>>> Take
    >>>> > a
    >>>> > > look at this little document, I mean even microsoft doesn't recommend
    >>>> > using
    >>>> > > the Session object.
    >>>> > >
    >>>> > > http://support.microsoft.com/support.../Q258/6/99.ASP
    >>>> > >
    >>>> > > Although once again Devins message is 100% correct cause it will
    >>>> work...I
    >>>> > > still though you might want a second opinion. Remeber, the Web
    >>>business
    >>>> > has
    >>>> > > proven that the dumbest ideas in the world can make money on the

    >net
    >>>> which
    >>>> > > means a small program that was ment to only work on one machine

    can
    >>>> > > overnight need to be placed on a webfarm.
    >>>> > >
    >>>> > > Once again, SESSION = EVIL
    >>>> > >
    >>>> > > Just my two cents,
    >>>> > >
    >>>> > > --
    >>>> > > Hope this Helps,
    >>>> > >
    >>>> > > Lee Amar
    >>>> > > CTO OSTNet OpenSource Technologies
    >>>> > > Advanced Computing Demands
    >>>> > > Advanced Gaming Breaks
    >>>> > > lior_amar@hotmail.com
    >>>> > >
    >>>> > >
    >>>> > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote in message
    >>>> > > news:3953be1f$1@news.devx.com...
    >>>> > > > OK. The easiest way to do this is by setting a simple Session
    >>>> > > > Variable. From your login page, once you have determined that

    >the
    >>>> > > > login is valid set something like:
    >>>> > > > Session("blnGoodUser") = True
    >>>> > > >
    >>>> > > > Then at the top of each page to be protected, check this flag,

    >and
    >>>> > > > if it is not present, redirect the browser to the login page:
    >>>> > > >
    >>>> > > > If Not Session("blnGoodUser") Then
    >>>> > > > Response.Clear
    >>>> > > > Response.Redirect("login.asp")
    >>>> > > > Response.End
    >>>> > > > End If
    >>>> > > >
    >>>> > > > Hope This Helps!
    >>>> > > >
    >>>> > > > --
    >>>> > > >
    >>>> > > > -Devin
    >>>> > > > ______________________________________________
    >>>> > > > Get on your feet and do the Funky Alphonso!
    >>>> > > >
    >>>> > > >
    >>>> > > >
    >>>> > > > "portly" <portly@coolemail.com> wrote in message
    >>>> > > > news:3953aaec@news.devx.com...
    >>>> > > > >
    >>>> > > > > I want to have it so you must enter though another page to view
    >>>> > > > the new page.
    >>>> > > > >
    >>>> > > > > I have online forms that I want to keep from being directly
    >>>> > > > accessed. They
    >>>> > > > > must go throught a client login first.
    >>>> > > > >
    >>>> > > > >
    >>>> > > > > Portly
    >>>> > > > >
    >>>> > > > >
    >>>> > > > >
    >>>> > > > >
    >>>> > > > >
    >>>> > > > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote:
    >>>> > > > > >I'm not quite clear on you question. Do you want to block
    >>>> > > > > >everyone from viewing a specific page(es), or are you wanting
    >>>> > > > to
    >>>> > > > > >block a specific user(s) from viewing anything?
    >>>> > > > > >
    >>>> > > > > >--
    >>>> > > > > >
    >>>> > > > > > -Devin
    >>>> > > > > > ______________________________________________
    >>>> > > > > > Get on your feet and do the Funky Alphonso!
    >>>> > > > > >
    >>>> > > > > >
    >>>> > > > > >
    >>>> > > > > >"Portly" <portly@coolemail.com> wrote in message
    >>>> > > > > >news:3953a3f5$1@news.devx.com...
    >>>> > > > > >>
    >>>> > > > > >> Does anyone know to eliminate a user from accessing a page

    >>by
    >>>> > > > > >just putting
    >>>> > > > > >> in the address? I know that can be eliminated by script

    code
    >>>> > > > > >but how???
    >>>> > > > > >>
    >>>> > > > > >>
    >>>> > > > > >> thanks in advance
    >>>> > > > > >>
    >>>> > > > > >> Portly
    >>>> > > > > >
    >>>> > > > > >
    >>>> > > > >
    >>>> > > >
    >>>> > > >
    >>>> > >
    >>>> > >
    >>>> >
    >>>> >
    >>>>
    >>>>
    >>>
    >>>

    >>

    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center