| Standard practice: login pages [message #175799] |
Thu, 27 October 2011 18:29  |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
What is the standard practice of restricting access to web pages by
user-login ?
In othere words users are allowed to view pages after logging in with
password.
Thanks.
|
|
|
|
| Re: Standard practice: login pages [message #175800 is a reply to message #175799] |
Thu, 27 October 2011 18:32  |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
> What is the standard practice of restricting access to web pages by
> user-login ?
>
> In othere words users are allowed to view pages after logging in with
> password.
>
The word "practice" here means method of programming with, eg PHP, java etc.
|
|
|
|
| Re: Standard practice: login pages [message #175804 is a reply to message #175800] |
Thu, 27 October 2011 04:24 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/27/2011 2:32 PM, sl@exabyte wrote:
>> What is the standard practice of restricting access to web pages by
>> user-login ?
>>
>> In othere words users are allowed to view pages after logging in with
>> password.
>>
>
> The word "practice" here means method of programming with, eg PHP, java etc.
>
>
Force them to log in and don't give them access until their credentials
have been validated.
Beyond that, there are numerous ways to restrict access - from .htaccess
to scripts (php or otherwise).
If you want more details you need to describe your problem better.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Standard practice: login pages [message #175805 is a reply to message #175804] |
Thu, 27 October 2011 04:57 |
Geoff Muldoon
Messages: 19
Registered: July 2011
Karma: 0
|
Junior Member |
|
|
jstucklex(at)attglobal(dot)net says...
>
> On 10/27/2011 2:32 PM, sl@exabyte wrote:
>>> What is the standard practice of restricting access to web pages by
>>> user-login ?
> Force them to log in and don't give them access until their
credentials
> have been validated.
>
> Beyond that, there are numerous ways to restrict access - from .htaccess
> to scripts (php or otherwise).
>
> If you want more details you need to describe your problem better.
In particular:
Does everyone log in using the same set of username/password
credentials, or is it individualised?
If multiple credentials are used, do they all resolve to an identical
set of user privileges?
Will multi-page transactions be possible?
.... and that's just a starter ...
GM
|
|
|
|
| Re: Standard practice: login pages [message #175806 is a reply to message #175805] |
Thu, 27 October 2011 22:00 |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
> In particular:
>
> Does everyone log in using the same set of username/password
> credentials, or is it individualised?
>
> If multiple credentials are used, do they all resolve to an identical
> set of user privileges?
>
> Will multi-page transactions be possible?
>
> ... and that's just a starter ...
>
I thinking of the following scenario:
1. Each user logs in with its own user name and password.
2. Multi-pages possible, eg view payment records, current user selections
etc.
3. Certain services are accessible after logging in, eg selection of items,
payment.
4. As of now, all users have the same previleges.
I think it is like CPanel, but not that complicated.
Thanks.
|
|
|
|
| Re: Standard practice: login pages [message #175807 is a reply to message #175806] |
Thu, 27 October 2011 06:03 |
Geoff Muldoon
Messages: 19
Registered: July 2011
Karma: 0
|
Junior Member |
|
|
ecp_gen(at)my-rialto(dot)com says...
>> Does everyone log in using the same set of username/password
>> credentials, or is it individualised?
>>
>> If multiple credentials are used, do they all resolve to an identical
>> set of user privileges?
>>
>> Will multi-page transactions be possible?
>>
>> ... and that's just a starter ...
>>
>
> I thinking of the following scenario:
>
> 1. Each user logs in with its own user name and password.
>
> 2. Multi-pages possible, eg view payment records, current user selections
> etc.
>
> 3. Certain services are accessible after logging in, eg selection of items,
> payment.
>
> 4. As of now, all users have the same previleges.
>
> I think it is like CPanel, but not that complicated.
Create a simple php function that checks to see if a user has already
authenticated, return Y/N.
Call the function at the top of every page except the logon/off page:
if auth = 'N' direct to logon page
if auth = 'Y' do whatever the page is supposed to do
Store the user/passwd details in a database.
Maintain the logged-in status of users using a session cookie.
GM
|
|
|
|
| Re: Standard practice: login pages [message #175808 is a reply to message #175807] |
Thu, 27 October 2011 23:14 |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
>> I thinking of the following scenario:
>>
>> 1. Each user logs in with its own user name and password.
>>
>> 2. Multi-pages possible, eg view payment records, current user
>> selections etc.
>>
>> 3. Certain services are accessible after logging in, eg selection of
>> items, payment.
>>
>> 4. As of now, all users have the same previleges.
>>
>> I think it is like CPanel, but not that complicated.
>
> Create a simple php function that checks to see if a user has already
> authenticated, return Y/N.
>
> Call the function at the top of every page except the logon/off page:
> if auth = 'N' direct to logon page
> if auth = 'Y' do whatever the page is supposed to do
>
> Store the user/passwd details in a database.
>
> Maintain the logged-in status of users using a session cookie.
>
With this tip, I think it will save a lot of my time banging my head around.
Thanks a lot.
|
|
|
|
| Re: Standard practice: login pages [message #175809 is a reply to message #175806] |
Thu, 27 October 2011 06:43 |
houghi
Messages: 45
Registered: September 2011
Karma: 0
|
Member |
|
|
sl@exabyte wrote:
> 4. As of now, all users have the same previleges.
Will that change? If so, it will be easier to do that now. Much easier
then to add it later. Then the chalange might be if this is per
group or if there are exceptions.
e.g.
PageA is for all people
PageB is for logged in people
PageC is for people from accouunting
PageD is for people from HR
PageE is for people from sales
Still easy. It becomes a bit harder if e.g. a manager should be able to
see both PageC and PageE and not PageD.
If it is a larger group of people, you need to define this as soon as
possible and it can mean a lot of work up front. It will save you a lot
afterwards.
You need to re-define the structure of your company (or whatever it is
you intend it for) and see if there are exceptions. e.g. people who work
in two departments.
But perhaps that will never be needed and doing a standard will be
enough. A standard would be something like
Guest, User, Maintainer, Admin.
Guest is not logged in, User is logged in, Maintainer is logged in with
e.g. add and edit abilities, Admin can also delete.
Then all you need to do is put that in a database (unless it is a very
small number of people) and use that database to see if a person is
allowed or not. Session cookies will do the rest.
houghi
--
But I will accept the rules that you feel necessary to your freedom. I am
free, no matter what rules surround me. If I find them tolerable, I
tolerate them; if I find them too obnoxious, I break them. I am free
because I know that I alone am morally responsible for everything I do.
|
|
|
|
| Re: Standard practice: login pages [message #175810 is a reply to message #175809] |
Fri, 28 October 2011 01:10 |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
>> 4. As of now, all users have the same previleges.
>
> Will that change? If so, it will be easier to do that now. Much easier
> then to add it later. Then the chalange might be if this is per
> group or if there are exceptions.
>
> e.g.
> PageA is for all people
> PageB is for logged in people
> PageC is for people from accouunting
> PageD is for people from HR
> PageE is for people from sales
>
> Still easy. It becomes a bit harder if e.g. a manager should be able
> to see both PageC and PageE and not PageD.
>
> If it is a larger group of people, you need to define this as soon as
> possible and it can mean a lot of work up front. It will save you a
> lot afterwards.
>
> You need to re-define the structure of your company (or whatever it is
> you intend it for) and see if there are exceptions. e.g. people who
> work in two departments.
>
> But perhaps that will never be needed and doing a standard will be
> enough. A standard would be something like
> Guest, User, Maintainer, Admin.
>
> Guest is not logged in, User is logged in, Maintainer is logged in
> with e.g. add and edit abilities, Admin can also delete.
>
> Then all you need to do is put that in a database (unless it is a very
> small number of people) and use that database to see if a person is
> allowed or not. Session cookies will do the rest.
>
This is certainly helpful; a lot of thought has gone into it.
I shall take note. Thanks.
|
|
|
|
| Re: Standard practice: login pages [message #175811 is a reply to message #175808] |
Thu, 27 October 2011 09:21 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
sl@exabyte wrote:
>> Create a simple php function that checks to see if a user has already
>> authenticated, return Y/N.
>>
>> Call the function at the top of every page except the logon/off page:
>> if auth = 'N' direct to logon page
>> if auth = 'Y' do whatever the page is supposed to do
>>
>> Store the user/passwd details in a database.
>>
>> Maintain the logged-in status of users using a session cookie.
>
> With this tip, I think it will save a lot of my time banging my head
> around.
Of course, the competent and more efficient solution is to return a boolean
from a session object's method.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
|
|
|
|
| Re: Standard practice: login pages [message #175817 is a reply to message #175811] |
Thu, 27 October 2011 13:31 |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
> Of course, the competent and more efficient solution is to return a
> boolean from a session object's method.
>
There seems to be a lot of things to dig, but I am not worried, for I think
I shall be digging at the correct path.
Thanks.
|
|
|
|
| Re: Standard practice: login pages [message #175823 is a reply to message #175810] |
Thu, 27 October 2011 17:19 |
houghi
Messages: 45
Registered: September 2011
Karma: 0
|
Member |
|
|
sl@exabyte wrote:
> This is certainly helpful; a lot of thought has gone into it.
>
> I shall take note. Thanks.
The main thing perhaps to take from it is to define first what you want.
Then how you do it will be much easier as you know what you are looking
for. Plan for the future as well as otherwise restarting all over bill
be easier then to adapt what you have
What I have done in the past with something similar was to first look at
what I want, then look up an open source project that does something
similar, 'steal' that and adapt it.
houghi
--
This is written under the inluence of the following:
> Artist : Emilie Autumn
> Song : Visions
> Album : Your Sugar Sits Untouched
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]