Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #3581 > unrolled thread

Standard practice: login pages

Back to article view | Back to comp.lang.php

Contents

  Standard practice: login pages "sl@exabyte" <ecp_gen@my-rialto.com> - 2011-10-27 11:29 -0700
    Re: Standard practice: login pages "sl@exabyte" <ecp_gen@my-rialto.com> - 2011-10-27 11:32 -0700
      Re: Standard practice: login pages Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-27 00:24 -0400
        Re: Standard practice: login pages Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2011-10-27 15:57 +1100
          Re: Standard practice: login pages "sl@exabyte" <ecp_gen@my-rialto.com> - 2011-10-27 15:00 -0700
            Re: Standard practice: login pages Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2011-10-27 17:03 +1100
              Re: Standard practice: login pages "sl@exabyte" <ecp_gen@my-rialto.com> - 2011-10-27 16:14 -0700
                Re: Standard practice: login pages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-27 11:21 +0200
                  Re: Standard practice: login pages "sl@exabyte" <sb5309@hotmail.com> - 2011-10-27 21:31 +0800
            Re: Standard practice: login pages houghi <houghi@houghi.org.invalid> - 2011-10-27 08:43 +0200
              Re: Standard practice: login pages "sl@exabyte" <ecp_gen@my-rialto.com> - 2011-10-27 18:10 -0700
                Re: Standard practice: login pages houghi <houghi@houghi.org.invalid> - 2011-10-27 19:19 +0200

#3581 — Standard practice: login pages

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. 

[toc] | [next] | [standalone]

#3582

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

[toc] | [prev] | [next] | [standalone]

#3586

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#3587

jstucklex@attglobal.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

[toc] | [prev] | [next] | [standalone]

#3588

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

[toc] | [prev] | [next] | [standalone]

#3589

ecp_gen@my-rialto.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

[toc] | [prev] | [next] | [standalone]

#3590

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

[toc] | [prev] | [next] | [standalone]

#3593

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

[toc] | [prev] | [next] | [standalone]

#3599

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

[toc] | [prev] | [next] | [standalone]

#3591

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.

[toc] | [prev] | [next] | [standalone]

#3592

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

[toc] | [prev] | [next] | [standalone]

#3605

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web