Question about authenticating people...

The subject might be a little misleading... But I couldn't think of
how better to describe it in a small sentence :)

What I'm wondering is, I have a program that accesses a database and
displays the info in that database... I know, nothing revolutionary
about it... I plan on setting up a database per customer who uses my
system, and what I would like to do is have everyone go to the same
address to login... Such as:

raoset.com/oldb/ they enter their username/password and get redirected
to their site... Or at least pull up their database...

Now that I'm typing this out, I may have thought of away to do this...

Set the main page, so that when you login, it accesses a master
database, which has the username, password, and database name stored
in it. Write the database name to a session variable, which I could
then use in my mysql connect file for the database....

Does that make sense? Thoughts? Problems? RTFM's? :)


--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruim@raoset.com

Jason Pruim wrote:
> The subject might be a little misleading... But I couldn't think of how
> better to describe it in a small sentence :)
>
> What I'm wondering is, I have a program that accesses a database and
> displays the info in that database... I know, nothing revolutionary
> about it... I plan on setting up a database per customer who uses my
> system, and what I would like to do is have everyone go to the same
> address to login... Such as:
>
> raoset.com/oldb/ they enter their username/password and get redirected
> to their site... Or at least pull up their database...
>
> Now that I'm typing this out, I may have thought of away to do this...
>
> Set the main page, so that when you login, it accesses a master
> database, which has the username, password, and database name stored in
> it. Write the database name to a session variable, which I could then
> use in my mysql connect file for the database....
>
> Does that make sense? Thoughts? Problems? RTFM's? :)

Assuming you mean raoset.com is not the domain of their site you would
need to pass the database name to their site some way other than via a
session since the session is tied to the domain name (no way around that
I'm afraid). This clearly makes it a bit insecure so you might want to
rethink how you're doing this.

Maybe they select/enter their domain name on the login form, then you
can use a bit of JS to have the form submit to a script on their site.
This gives the best of both worlds... they all go to the same URL to log
in, but you don't need to pass things like database names between sites
via the browser (which is insecure).

-Stut

--
http://stut.net/

On Nov 27, 2007, at 3:48 PM, Stut wrote:

> Jason Pruim wrote:
>> The subject might be a little misleading... But I couldn't think of
>> how better to describe it in a small sentence :)
>> What I'm wondering is, I have a program that accesses a database
>> and displays the info in that database... I know, nothing
>> revolutionary about it... I plan on setting up a database per
>> customer who uses my system, and what I would like to do is have
>> everyone go to the same address to login... Such as:
>> raoset.com/oldb/ they enter their username/password and get
>> redirected to their site... Or at least pull up their database...
>> Now that I'm typing this out, I may have thought of away to do
>> this...
>> Set the main page, so that when you login, it accesses a master
>> database, which has the username, password, and database name
>> stored in it. Write the database name to a session variable, which
>> I could then use in my mysql connect file for the database....
>> Does that make sense? Thoughts? Problems? RTFM's? :)
>
> Assuming you mean raoset.com is not the domain of their site you
> would need to pass the database name to their site some way other
> than via a session since the session is tied to the domain name (no
> way around that I'm afraid). This clearly makes it a bit insecure so
> you might want to rethink how you're doing this.
>
> Maybe they select/enter their domain name on the login form, then
> you can use a bit of JS to have the form submit to a script on their
> site. This gives the best of both worlds... they all go to the same
> URL to log in, but you don't need to pass things like database names
> between sites via the browser (which is insecure).
>
> -Stut


The database they are connecting to is on my site. That's what they
would be logging into. I'm trying to avoid something like this:
HTTP://www.raoset.com/oldb/customers/customer1
HTTP://www.raoset.com/oldb/customers/customer2

etc. etc. etc.

What I would like is to have everyone go to: HTTP://www.raoset.com/oldb/login.php
and then be able to pull up there database from their login
credentials.

Does that make it clear as mud?


--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruim@raoset.com

Jason Pruim wrote:
>
> On Nov 27, 2007, at 3:48 PM, Stut wrote:
>
>> Jason Pruim wrote:
>>> The subject might be a little misleading... But I couldn't think of
>>> how better to describe it in a small sentence :)
>>> What I'm wondering is, I have a program that accesses a database and
>>> displays the info in that database... I know, nothing revolutionary
>>> about it... I plan on setting up a database per customer who uses my
>>> system, and what I would like to do is have everyone go to the same
>>> address to login... Such as:
>>> raoset.com/oldb/ they enter their username/password and get
>>> redirected to their site... Or at least pull up their database...
>>> Now that I'm typing this out, I may have thought of away to do this...
>>> Set the main page, so that when you login, it accesses a master
>>> database, which has the username, password, and database name stored
>>> in it. Write the database name to a session variable, which I could
>>> then use in my mysql connect file for the database....
>>> Does that make sense? Thoughts? Problems? RTFM's? :)
>>
>> Assuming you mean raoset.com is not the domain of their site you would
>> need to pass the database name to their site some way other than via a
>> session since the session is tied to the domain name (no way around
>> that I'm afraid). This clearly makes it a bit insecure so you might
>> want to rethink how you're doing this.
>>
>> Maybe they select/enter their domain name on the login form, then you
>> can use a bit of JS to have the form submit to a script on their site.
>> This gives the best of both worlds... they all go to the same URL to
>> log in, but you don't need to pass things like database names between
>> sites via the browser (which is insecure).
>>
>> -Stut
>
>
> The database they are connecting to is on my site. That's what they
> would be logging into. I'm trying to avoid something like this:
> HTTP://www.raoset.com/oldb/customers/customer1
> HTTP://www.raoset.com/oldb/customers/customer2
>
> etc. etc. etc.
>
> What I would like is to have everyone go to:
> HTTP://www.raoset.com/oldb/login.php and then be able to pull up there
> database from their login credentials.
>
> Does that make it clear as mud?

Yeah, no-brainer - use a session if you're already using a session on
the customer sites.

Personally I'd store a mapping of dirname (customer1, customer2) to
database name (customer1db, customer2db) in files so you don't need to
pass anything from request to request. You just use the directory being
accessed to lookup the DB. But then I consider sessions evil and
something to be avoided wherever possible, you may not share that opinion.

-Stut

--
http://stut.net/

On Nov 27, 2007, at 3:56 PM, Stut wrote:

> Jason Pruim wrote:
>> On Nov 27, 2007, at 3:48 PM, Stut wrote:
>>> Jason Pruim wrote:
>>>> The subject might be a little misleading... But I couldn't think
>>>> of how better to describe it in a small sentence :)
>>>> What I'm wondering is, I have a program that accesses a database
>>>> and displays the info in that database... I know, nothing
>>>> revolutionary about it... I plan on setting up a database per
>>>> customer who uses my system, and what I would like to do is have
>>>> everyone go to the same address to login... Such as:
>>>> raoset.com/oldb/ they enter their username/password and get
>>>> redirected to their site... Or at least pull up their database...
>>>> Now that I'm typing this out, I may have thought of away to do
>>>> this...
>>>> Set the main page, so that when you login, it accesses a master
>>>> database, which has the username, password, and database name
>>>> stored in it. Write the database name to a session variable,
>>>> which I could then use in my mysql connect file for the
>>>> database....
>>>> Does that make sense? Thoughts? Problems? RTFM's? :)
>>>
>>> Assuming you mean raoset.com is not the domain of their site you
>>> would need to pass the database name to their site some way other
>>> than via a session since the session is tied to the domain name
>>> (no way around that I'm afraid). This clearly makes it a bit
>>> insecure so you might want to rethink how you're doing this.
>>>
>>> Maybe they select/enter their domain name on the login form, then
>>> you can use a bit of JS to have the form submit to a script on
>>> their site. This gives the best of both worlds... they all go to
>>> the same URL to log in, but you don't need to pass things like
>>> database names between sites via the browser (which is insecure).
>>>
>>> -Stut
>> The database they are connecting to is on my site. That's what they
>> would be logging into. I'm trying to avoid something like this:
>> HTTP://www.raoset.com/oldb/customers/customer1
>> HTTP://www.raoset.com/oldb/customers/customer2
>> etc. etc. etc.
>> What I would like is to have everyone go to: HTTP://www.raoset.com/oldb/login.php
>> and then be able to pull up there database from their login
>> credentials.
>> Does that make it clear as mud?
>
> Yeah, no-brainer - use a session if you're already using a session
> on the customer sites.
>
> Personally I'd store a mapping of dirname (customer1, customer2) to
> database name (customer1db, customer2db) in files so you don't need
> to pass anything from request to request. You just use the directory
> being accessed to lookup the DB. But then I consider sessions evil
> and something to be avoided wherever possible, you may not share
> that opinion.


Okay, I'll start writing code and see when I hit issues :)

Just for my own curiosity, why do you think sessions are evil? I
haven't found a better way to store my variables between different
pages... Other then always posting them in either $_POST or $_GET each
time... But that can add up quite a bit on a complicated site though...

Thanks for looking though!


--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruim@raoset.com

adding a client name to the login process might make that easier

and it forces a sort of 2 factor authentication making the database 'hopefully' harder to crack

bastien> From: japruim@raoset.com> To: php-general@lists.php.net> Date: Tue, 27 Nov 2007 15:30:32 -0500> Subject: [php] Question about authenticating people...> > The subject might be a little misleading... But I couldn't think of > how better to describe it in a small sentence :)> > What I'm wondering is, I have a program that accesses a database and > displays the info in that database... I know, nothing revolutionary > about it... I plan on setting up a database per customer who uses my > system, and what I would like to do is have everyone go to the same > address to login... Such as:> > raoset.com/oldb/ they enter their username/password and get redirected > to their site... Or at least pull up their database...> > Now that I'm typing this out, I may have thought of away to do this...> > Set the main page, sothat when you login, it accesses a master > database, which has the username, password, and database name stored > in it. Write the database name to a session variable, which I could > then use in my mysql connect file for the database....> > Does that make sense? Thoughts? Problems? RTFM's? :)> > > --> > Jason Pruim> Raoset Inc.> Technology Manager> MQC Specialist> 3251 132nd ave> Holland, MI, 49424> www.raoset.com> japruim@raoset.com> > -- > PHP General Mailing List (http://www.php.net/)> To unsubscribe, visit: http://www.php.net/unsub.php>
__________________________________________________ _______________
Express yourself with free Messenger emoticons. Get them today!
http://www.freemessengeremoticons.ca/?icid=EMENCA122

Jason Pruim wrote:
> Just for my own curiosity, why do you think sessions are evil? I haven't
> found a better way to store my variables between different pages...
> Other then always posting them in either $_POST or $_GET each time...
> But that can add up quite a bit on a complicated site though...

Sessions in the way that most PHP developers think about them are an
enemy of horizontal scalability, but if slightly alter the way you think
about how your app works you can effectively remove the need for this
type of session.

Think about how much info you need to store between page requests that
isn't already available to you some other way, in a database for
example. Now consider that if your app needs to scale then chances are
you'll end up with your session storage in a database. What do you gain
by extracting that data from it's natural home in the database and
putting it into another location in the database for the duration of a
users visit?

The one thing you do need to transfer from request to request is
something to identify the logged in user. This is done in the same way
sessions pass their identifier, in a cookie or in the URL. The only
difference is that you need to encrypt it to make it a bit harder to
fake. I generally include a timestamp in the encrypted cookie so I can
impose a hard limit on the lifetime of a session. Normal rules for good
encryption apply here, but bear in mind that every single request will
need to decrypt it, and potentially encrypt it too so don't go overboard.

Of course it's possible that the app you're working on will never need
to scale beyond one machine, but I have been involved in scaling too
many sites that weren't designed to do it to not plan for the
possibility in everything I do now.

Anyway, that's why I avoid using 'sessions' wherever possible - IMHO
there are better ways to achieve the same goal for most applications.

-Stut

--
http://stut.net/

Jason Pruim wrote:
> Set the main page, so that when you login, it accesses a master
> database, which has the username, password, and database name stored in
> it. Write the database name to a session variable, which I could then
> use in my mysql connect file for the database...

This sounds completely reasonable.

If all databases have the same structure, you
may consider having actually only one
database, identifying the records belonging
to a given customer by 'customer_id'.

This way maintenance and further development
of the 'databases' will be easier.

Iv

On Nov 27, 2007, at 6:01 PM, Stut wrote:

> Jason Pruim wrote:
>> Just for my own curiosity, why do you think sessions are evil? I
>> haven't found a better way to store my variables between different
>> pages... Other then always posting them in either $_POST or $_GET
>> each time... But that can add up quite a bit on a complicated site
>> though...
>
> Sessions in the way that most PHP developers think about them are an
> enemy of horizontal scalability, but if slightly alter the way you
> think about how your app works you can effectively remove the need
> for this type of session.
>
> Think about how much info you need to store between page requests
> that isn't already available to you some other way, in a database
> for example. Now consider that if your app needs to scale then
> chances are you'll end up with your session storage in a database.
> What do you gain by extracting that data from it's natural home in
> the database and putting it into another location in the database
> for the duration of a users visit?

One of the things I have in a session variable, is a search function
through the database, and then an export to excel option. Would I be
better to store that in a cookie rather then a session variable?

>
>
> The one thing you do need to transfer from request to request is
> something to identify the logged in user. This is done in the same
> way sessions pass their identifier, in a cookie or in the URL. The
> only difference is that you need to encrypt it to make it a bit
> harder to fake. I generally include a timestamp in the encrypted
> cookie so I can impose a hard limit on the lifetime of a session.
> Normal rules for good encryption apply here, but bear in mind that
> every single request will need to decrypt it, and potentially
> encrypt it too so don't go overboard.
>
> Of course it's possible that the app you're working on will never
> need to scale beyond one machine, but I have been involved in
> scaling too many sites that weren't designed to do it to not plan
> for the possibility in everything I do now.
>
> Anyway, that's why I avoid using 'sessions' wherever possible - IMHO
> there are better ways to achieve the same goal for most applications.


I'll have to look more into cookies before I can comment much on the
rest of the e-mail which I shall start doing now I believe :)


--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruim@raoset.com

Jason Pruim wrote:
>
> On Nov 27, 2007, at 6:01 PM, Stut wrote:
>
>> Jason Pruim wrote:
>>> Just for my own curiosity, why do you think sessions are evil? I
>>> haven't found a better way to store my variables between different
>>> pages... Other then always posting them in either $_POST or $_GET
>>> each time... But that can add up quite a bit on a complicated site
>>> though...
>>
>> Sessions in the way that most PHP developers think about them are an
>> enemy of horizontal scalability, but if slightly alter the way you
>> think about how your app works you can effectively remove the need for
>> this type of session.
>>
>> Think about how much info you need to store between page requests that
>> isn't already available to you some other way, in a database for
>> example. Now consider that if your app needs to scale then chances are
>> you'll end up with your session storage in a database. What do you
>> gain by extracting that data from it's natural home in the database
>> and putting it into another location in the database for the duration
>> of a users visit?
>
> One of the things I have in a session variable, is a search function
> through the database, and then an export to excel option. Would I be
> better to store that in a cookie rather then a session variable?

Not sure what you mean by this. If you mean the results of a search then
unless your search query takes longer than your average user will wait
then you really need to optimise your search system. Duplicating the
results into a session is extremely inefficient.

However, if you mean something else could you explain it so an idiot
(that's me) can understand it.

>> The one thing you do need to transfer from request to request is
>> something to identify the logged in user. This is done in the same way
>> sessions pass their identifier, in a cookie or in the URL. The only
>> difference is that you need to encrypt it to make it a bit harder to
>> fake. I generally include a timestamp in the encrypted cookie so I can
>> impose a hard limit on the lifetime of a session. Normal rules for
>> good encryption apply here, but bear in mind that every single request
>> will need to decrypt it, and potentially encrypt it too so don't go
>> overboard.
>>
>> Of course it's possible that the app you're working on will never need
>> to scale beyond one machine, but I have been involved in scaling too
>> many sites that weren't designed to do it to not plan for the
>> possibility in everything I do now.
>>
>> Anyway, that's why I avoid using 'sessions' wherever possible - IMHO
>> there are better ways to achieve the same goal for most applications.
>
>
> I'll have to look more into cookies before I can comment much on the
> rest of the e-mail which I shall start doing now I believe :)

Like I said it's possible you'll never need to scale beyond one machine,
or if you do maybe you're working for a company with pots of spare cash.
Having said that, IMHO being good at avoiding sessions is a worthy skill
to gain.

-Stut

--
http://stut.net/