I suggest you look at the article restricting page access by Kevin Yank on
http://sitepoint.com... I used it for the basis of what I use on every site
now, and it will give you a better understanding of sessions, logging in,
registering, etc etc.

Other comments included in your email below:


on 02/08/02 5:56 AM, PHP mail ([EMAIL PROTECTED]) wrote:

> 
> If anyone responds to this thanks a lot because this is a lot to ask. I've
> never coded anything for a paying customer.
> 
> I'll be using Apache, MySQL and php of course.
> 
> Or... how about this application already exists somewhere??

see above


> Requirements/Design
> -------------------
> 1. Any page requiring authentication should be in a secure directory.  The
> login for the directory will be issued behind the scenes once the user is
> authenticated.  This prevents anyone from by passing the login.

They don't need to be in a different directory.  If you use Kevin's code as
a base, all you'll have to do is include a single file at the top of any
page you wish to make restricted.


> 2. Once you login once for a session all other pages requiring
> authentication become accessible to you (i.e record login in a cookie).

Kevin's code uses sessions (the smart way to do this stuff), but
unfortunately his code relies only cookies, not sessions in the URL.


> 2. If you do not yet have a username/password then you can click on
> register, where you enter the following:
> 
> Name *
> Title
> Company *
> Address *
> Tel
> Fax
> Email *
> LicenseId *
> Username *
> Password *
> Confirm Password *
> 
> * = required
> Username must be unique.
> LicenseId must exist in a table of currently active licenses maintained by
> KINESYS.

you'll have to modify kevin's code / table to acomodate you needs, as I
have.


> 3. If registration is successful then the account is stored in the database
> and the user continues to the originally requested page.

yup, all taken care of


> 4. On the login page there should be a "Forgotten password?" link.  When you
> click it you have to enter your email address and if it exists in the
> database, the username and password is emailed to you.

not as easy, because Kevin (rightly so) encrypts passwords with MySQL's
PASSWORD(), a one-way encryption.

I built a password-resetting program instead, which generates a new password
and emails it to the user if they forget the old one.

... or you could store the passwords in clear text, then emailing them would
be possible.


> 5. Each login with date and time should be recorded in the database linked
> to the Username.  Ideally each download should also be recorded.

this would be an extension to the code, but reasonably straight forward.
Downloads will take some time to nail, but everything else will be pretty
straight forward.


> 6. The pages requiring authentication should be in a secure directory.  The
> login for the directory will be issued behind the scenes.  This prevents
> anyone from by passing the login.

it won't be needed with kev's code.  the basic structure of his code is:

check for existing user/session
    if yes, show page
    if no, show login form and a link to sign-up form

if login form was submitted, validate everything, set a session, show the
page, else show "sorry, invalid login"

if a sign-up form was submitted, validate input, add to db, and send a
confirmation email to the user (i think), and once confirmed, they'll be
able to login.


> 7. There must be an administration page in the secure directory that allows
> KINESYS to maintain the list of LicenseIds in the License table, and to view
> the user and event tables.

I have an extra column in my users table which is called admin_clearance
(1|0)... if they have admin clearance, it's noted in the session, and
they're able to do more "stuff", and access admin-only pages (an extension
to kev's code.


> Here is my take on the initial database schema.
> 
> Table: License
> Primary Key: LicenseId
> 
> Table: User
> Primary key: UserId (autoincrement)
> Required Unique Field: UserName
> Required Field: Password
> Required Field: Name
> Field: Title
> Required Field: Company
> Required Field: Address1
> Required Field: Address2
> Required Field: Address3
> Required Field: Address4
> Field: Tel
> Field: Fax
> Required Field: Email
> Required Foreign Key: LicenseId
> 
> Table: Event
> Primary Key: EventId (autoincrement)
> Required Field: Timestamp
> Required Foreign Key: UserId
> Required Field: Description (e.g. "Login", "Downloaded ALPS LT 2.61.1")



Suffice to say, this is a big project.  If it's your first, be warned that
there is a LOT of work here, especially if you're new to sessions,
encryption, data validation, etc etc.

But the good news is that kev's stuff will be a great start, and the
tutorial/code was the basis for everything I know and do with sessions these
days.

The article was written b4 the new global arrays ($_SESSION etc) so the code
has to be modified a little if you have register_globals off in your
php.ini.



You'll find that the code you write (essentially an include file at the top
of any page you want to restrict, plus a few other scripts for sign-up,
password reset, log-out, etc) will be highly portable.  I just grab the code
base from my library folder, and it plugs in to the new site with a simple
config change of a few lines.


This code is worth a lot, especially if it's done right.  But if you think
you can use it over and over and over, then perhaps the price you charge
will not be proportionate to the hours you spent on the code.

Let's say you spend 10 hours perfecting, tweaking and testing the shit out
of the code.  You could charge the client for 10 hours, but if you feel this
is out of their budget, you could license the code to them at a fraction of
your original cost (say 4 hours-ish), and by doing this with many clients,
make a profit on the code library over the coming months.


I guess what I'm trying to say is just quote them a price you think they'll
accept, do it right, spend heaps of time on it, perfect it, and then re-use
the code over and over with other clients to make your time back, and make a
profit from it.


Good luck,


Justin French


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to