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
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
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
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>
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
>>> > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>>
>>>
>>
>>
>
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
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
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
>
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
>>>> > > > > >
>>>> > > > > >
>>>> > > > >
>>>> > > >
>>>> > > >
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>>
>>>>
>>>
>>>
>>
>
