472,146 Members | 1,208 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,146 software developers and data experts.

maintain a single session across multiple servers

Hello,

I am trying to find a solution to a login mechanism for different
domains on different servers with PHP5.

I have one main domain with the user data and several other domains that
need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is
this possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir
Jun 10 '07 #1
13 8403
Samir Chouaieb wrote:
Hello,

I am trying to find a solution to a login mechanism for different
domains on different servers with PHP5.

I have one main domain with the user data and several other domains that
need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is
this possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir
No, it's not. Cookies are designed to be domain specific. For security
reasons, the browser won't send a cookie belonging to one domain on to
another domain.

If all of these sites are so closely related, why are they different sites?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 10 '07 #2
Hi,

thanks first of all for your answer.
No, it's not. Cookies are designed to be domain specific.
For security reasons, the browser won't send a cookie
belonging to one domain on to another domain.
You took only the cookies into consideration as a way to store session-ids.
If all of these sites are so closely related, why are they
different sites?
Take as an example a set of partner online shops that have a central
login mechanism.
If the login pages of the online shops call a dedicated php-page on the
main domain that achieves the login if not done aready and gives the
session-id back to the referer page in the url or as POST variable.

if the different shops have the same php-path for session variables on
the main-domain server, then they will be able to read the content of
the session.

Does this make a sense. Or am I dreaming?
Regards
Samir

Jerry Stuckle wrote:
Samir Chouaieb wrote:
>Hello,

I am trying to find a solution to a login mechanism for different
domains on different servers with PHP5.

I have one main domain with the user data and several other domains
that need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is
this possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir

No, it's not. Cookies are designed to be domain specific. For security
reasons, the browser won't send a cookie belonging to one domain on to
another domain.

If all of these sites are so closely related, why are they different sites?

Jun 10 '07 #3
Samir Chouaieb wrote:
Jerry Stuckle wrote:
>Samir Chouaieb wrote:
>>Hello,

I am trying to find a solution to a login mechanism for different
domains on different servers with PHP5.

I have one main domain with the user data and several other domains
that need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is
this possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir

No, it's not. Cookies are designed to be domain specific. For
security reasons, the browser won't send a cookie belonging to one
domain on to another domain.

If all of these sites are so closely related, why are they different
sites?

Hi,

thanks first of all for your answer.
No, it's not. Cookies are designed to be domain specific.
For security reasons, the browser won't send a cookie
belonging to one domain on to another domain.

You took only the cookies into consideration as a way to store
session-ids.
>
If all of these sites are so closely related, why are they
different sites?

Take as an example a set of partner online shops that have a central
login mechanism.
If the login pages of the online shops call a dedicated php-page on the
main domain that achieves the login if not done aready and gives the
session-id back to the referer page in the url or as POST variable.

if the different shops have the same php-path for session variables on
the main-domain server, then they will be able to read the content of
the session.

Does this make a sense. Or am I dreaming?
Regards
Samir
(Top posting fixed)

No, I'm not talking about cookies which contain session id's. Any
cookie is domain specific. As will be the sessions, if you're smart.

Anything else like passing info back and forth in $_POST or $_GET
variables can be very easily fudged. And even if they all have the same
path on the server, there is a huge amount which can go wrong, as well
as huge potential security holes. For instance, the refer page can be
easily falsified. It's not hard at all.

I wouldn't even try it across multiple domains like this. And I ask
again - if these are so closely related, why aren't they the same
domain? They should be, IMHO. How many other sites do you see where one
signon covers multiple domains?

And please don't top post.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 10 '07 #4
On Jun 11, 12:52 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
<snip>
I wouldn't even try it across multiple domains like this. And I ask
again - if these are so closely related, why aren't they the same
domain? They should be, IMHO. How many other sites do you see where one
signon covers multiple domains?
Yahoo! (Flickr), Google (Blogger, Orkut)

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

Jun 10 '07 #5
R. Rajesh Jeba Anbiah wrote:
On Jun 11, 12:52 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
<snip>
>I wouldn't even try it across multiple domains like this. And I ask
again - if these are so closely related, why aren't they the same
domain? They should be, IMHO. How many other sites do you see where one
signon covers multiple domains?

Yahoo! (Flickr), Google (Blogger, Orkut)

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
And specifically which of those domains have one sign-in which then
allows you access to the other domains without having to sign in again?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 10 '07 #6

"Samir Chouaieb" <ch******@nospam.arcor.dewrote in message
news:46***********************@newsspool3.arcor-online.net...
Hello,

I am trying to find a solution to a login mechanism for different domains
on different servers with PHP5.

I have one main domain with the user data and several other domains that
need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is this
possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir

Why not just a central server that handles the the cookies? That way they
are stored w.r.t to the centeral server but the other servers can get the
information(through a request to the centeral server).

e.g., when the user wants to be "remembered" they would be temporarily
redirected to your centeral server where the cookie processing will take
place and it will probably need to contain more information such as which
server the request came from(or since you don't seem to care it would just
save it as normal).

Then any time cookie retrival needs to happen the opposite thing will
happen.

I think the only issue here is if multiple servers are serving to the same
users then there would need some way to synchronize but I thnk this isn't
that big of a problem.

If you go the central route then you could keep everything on that central
server and really just dish out stuff over the different domains. You just
need to write an interface for what you want.

Jon
Jun 10 '07 #7
Jon Slaughter wrote:
"Samir Chouaieb" <ch******@nospam.arcor.dewrote in message
news:46***********************@newsspool3.arcor-online.net...
>Hello,

I am trying to find a solution to a login mechanism for different domains
on different servers with PHP5.

I have one main domain with the user data and several other domains that
need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is this
possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir


Why not just a central server that handles the the cookies? That way they
are stored w.r.t to the centeral server but the other servers can get the
information(through a request to the centeral server).

e.g., when the user wants to be "remembered" they would be temporarily
redirected to your centeral server where the cookie processing will take
place and it will probably need to contain more information such as which
server the request came from(or since you don't seem to care it would just
save it as normal).

Then any time cookie retrival needs to happen the opposite thing will
happen.

I think the only issue here is if multiple servers are serving to the same
users then there would need some way to synchronize but I thnk this isn't
that big of a problem.

If you go the central route then you could keep everything on that central
server and really just dish out stuff over the different domains. You just
need to write an interface for what you want.

Jon

Jon,

The problem here is the remote servers will have no idea what the
current status is from the central server - they'll have no way to
communicate anything, even the session id.

If everything requiring a single signon were handled through the central
server, this would work. But it would require using frames and
basically the main server would be doing everything requiring signons.
So why even have the other servers/domains?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 11 '07 #8

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Vp******************************@comcast.com. ..
Jon Slaughter wrote:
>"Samir Chouaieb" <ch******@nospam.arcor.dewrote in message
news:46***********************@newsspool3.arcor-online.net...
>>Hello,

I am trying to find a solution to a login mechanism for different
domains on different servers with PHP5.

I have one main domain with the user data and several other domains that
need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is
this possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir


Why not just a central server that handles the the cookies? That way
they are stored w.r.t to the centeral server but the other servers can
get the information(through a request to the centeral server).

e.g., when the user wants to be "remembered" they would be temporarily
redirected to your centeral server where the cookie processing will take
place and it will probably need to contain more information such as which
server the request came from(or since you don't seem to care it would
just save it as normal).

Then any time cookie retrival needs to happen the opposite thing will
happen.

I think the only issue here is if multiple servers are serving to the
same users then there would need some way to synchronize but I thnk this
isn't that big of a problem.

If you go the central route then you could keep everything on that
central server and really just dish out stuff over the different domains.
You just need to write an interface for what you want.

Jon

Jon,

The problem here is the remote servers will have no idea what the current
status is from the central server - they'll have no way to communicate
anything, even the session id.
Why is this? There surely could be something implement sorta like
callbacks... or ajax.

essentially on the remote computer you have a php script that is called by
the central server when something chances or to pass on information. The php
script then could either write them to a file or use shared memory or maybe
run in the same process space as the session.

Sure there would have to be negotiations at the start but I don't see a
problem with it. Instead of passing session through a url, say, your doing
it over a remote connection.

For example,

User logs into RS(remote server). RS establishes a "session ID" for this
user and calls central server and passes this session ID. All other servers
are signaled that this user as logged into this server(or they could request
each time a user logs onto them). Every time a state is changed its
reflected back and forth. This isn't optimal of course and technically isn't
probably very good but it should work.

The main problem, I suppose, is creating a unique ID for the user. Would
have to atleast be the IP but then that causes problems with proxies and
stuff. Maybe there is a way though...

I really don't see the issue though. After all you could have two servers
running on the same computer but one listens on a different ip. Surely they
would not have any issues sharing a session? (it might require some new
software to handle it efficiently though) Doing it remotely shouldn't be
that much more of a problem(aside from the security issues).

of course I could be missing something but I don't think your reasoning is
valid as its pretty easy to synchronize status.

Jon


Jun 11 '07 #9
>The problem here is the remote servers will have no idea what the current
>status is from the central server - they'll have no way to communicate
anything, even the session id.
Assuming you can solve the problem of the session identifier
(something that can be dealt with by making the servers all have a
common domain with different subdomains), it is possible to use a
session save handler to store the session data in MySQL, not a local
file directory. This has potential to make the session data available
to multiple servers (a setup commonly used with round-robin DNS to
spread the load over several servers serving identical content).
You might have locking issues with changing the content of the
session, though. That might be solved with key changes (logging
in, logging out) handled by one specific server.

If you insist on no more than one session per user, you can use the
user id as a key for locating session data.

>Why is this? There surely could be something implement sorta like
callbacks... or ajax.

essentially on the remote computer you have a php script that is called by
the central server when something chances or to pass on information. The php
script then could either write them to a file or use shared memory or maybe
run in the same process space as the session.
Having the central server call all the other servers can give you trouble
if one of them goes down. (On the other hand, a central database can be
a single point of failure for the whole group of systems if not designed
carefully).
>Sure there would have to be negotiations at the start but I don't see a
problem with it. Instead of passing session through a url, say, your doing
it over a remote connection.

For example,

User logs into RS(remote server). RS establishes a "session ID" for this
user and calls central server and passes this session ID. All other servers
are signaled that this user as logged into this server(or they could request
each time a user logs onto them). Every time a state is changed its
reflected back and forth. This isn't optimal of course and technically isn't
probably very good but it should work.
I prefer to stick all this information in a database where the various
servers can access it. If necessary, the database can be replicated.
>The main problem, I suppose, is creating a unique ID for the user. Would
have to atleast be the IP but then that causes problems with proxies and
stuff. Maybe there is a way though...
If a user is required to log in, his user id may serve that purpose.
>I really don't see the issue though. After all you could have two servers
running on the same computer but one listens on a different ip. Surely they
would not have any issues sharing a session? (it might require some new
software to handle it efficiently though) Doing it remotely shouldn't be
that much more of a problem(aside from the security issues).

of course I could be missing something but I don't think your reasoning is
valid as its pretty easy to synchronize status.
Jun 11 '07 #10

"Gordon Burditt" <go***********@burditt.orgwrote in message
news:13*************@corp.supernews.com...
>>The problem here is the remote servers will have no idea what the
current
status is from the central server - they'll have no way to communicate
anything, even the session id.

Assuming you can solve the problem of the session identifier
(something that can be dealt with by making the servers all have a
common domain with different subdomains), it is possible to use a
session save handler to store the session data in MySQL, not a local
file directory. This has potential to make the session data available
to multiple servers (a setup commonly used with round-robin DNS to
spread the load over several servers serving identical content).
You might have locking issues with changing the content of the
session, though. That might be solved with key changes (logging
in, logging out) handled by one specific server.

If you insist on no more than one session per user, you can use the
user id as a key for locating session data.

>>Why is this? There surely could be something implement sorta like
callbacks... or ajax.

essentially on the remote computer you have a php script that is called by
the central server when something chances or to pass on information. The
php
script then could either write them to a file or use shared memory or
maybe
run in the same process space as the session.

Having the central server call all the other servers can give you trouble
if one of them goes down. (On the other hand, a central database can be
a single point of failure for the whole group of systems if not designed
carefully).
>>Sure there would have to be negotiations at the start but I don't see a
problem with it. Instead of passing session through a url, say, your doing
it over a remote connection.

For example,

User logs into RS(remote server). RS establishes a "session ID" for this
user and calls central server and passes this session ID. All other
servers
are signaled that this user as logged into this server(or they could
request
each time a user logs onto them). Every time a state is changed its
reflected back and forth. This isn't optimal of course and technically
isn't
probably very good but it should work.

I prefer to stick all this information in a database where the various
servers can access it. If necessary, the database can be replicated.
>>The main problem, I suppose, is creating a unique ID for the user. Would
have to atleast be the IP but then that causes problems with proxies and
stuff. Maybe there is a way though...

If a user is required to log in, his user id may serve that purpose.
No... You have to have some way for the other servers to recognize who the
user is when he comes to their page. Now if he is required to log into each
server then thats ok.. But if you want one server multiple logins then its
more difficult... although I suppose you could just broadcast the login
information to each one and they can create there own session id(although it
will then be hard to synch if they all have different session ids.

I was just giving some ideas though. I do not by any means think its
impossible. Just might require a little work.

Jon
Jun 11 '07 #11
Jerry Stuckle <js*******@attglobal.netwrote in
news:3P******************************@comcast.com:
>>How many other sites do you see where
one signon covers multiple domains?

Yahoo! (Flickr), Google (Blogger, Orkut)

And specifically which of those domains have one sign-in which then
allows you access to the other domains without having to sign in
again?
you can sign in at any location and be signed in across all related sites.
Jun 11 '07 #12
Jon Slaughter wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Vp******************************@comcast.com. ..
>Jon Slaughter wrote:
>>"Samir Chouaieb" <ch******@nospam.arcor.dewrote in message
news:46***********************@newsspool3.arco r-online.net...
Hello,

I am trying to find a solution to a login mechanism for different
domains on different servers with PHP5.

I have one main domain with the user data and several other domains that
need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is
this possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir

Why not just a central server that handles the the cookies? That way
they are stored w.r.t to the centeral server but the other servers can
get the information(through a request to the centeral server).

e.g., when the user wants to be "remembered" they would be temporarily
redirected to your centeral server where the cookie processing will take
place and it will probably need to contain more information such as which
server the request came from(or since you don't seem to care it would
just save it as normal).

Then any time cookie retrival needs to happen the opposite thing will
happen.

I think the only issue here is if multiple servers are serving to the
same users then there would need some way to synchronize but I thnk this
isn't that big of a problem.

If you go the central route then you could keep everything on that
central server and really just dish out stuff over the different domains.
You just need to write an interface for what you want.

Jon
Jon,

The problem here is the remote servers will have no idea what the current
status is from the central server - they'll have no way to communicate
anything, even the session id.

Why is this? There surely could be something implement sorta like
callbacks... or ajax.
OK, please explain exactly how you will do it. Ajax can't do it -
security restrictions (if properly implemented) limit Javascript calls
to the server the javascript was loaded from, for instance.

How are you going to callback a script on another server?
essentially on the remote computer you have a php script that is called by
the central server when something chances or to pass on information. The php
script then could either write them to a file or use shared memory or maybe
run in the same process space as the session.
OK, you call the remote computer and pass along the session id. But you
still can't pass that session id from the browser to the remote computer
- at least not by a cookie. And passing by get/post leaves you open to
all kinds of potential security problems.
Sure there would have to be negotiations at the start but I don't see a
problem with it. Instead of passing session through a url, say, your doing
it over a remote connection.
But you still need to relate that session to the user's browser. That's
the problem.
For example,

User logs into RS(remote server). RS establishes a "session ID" for this
user and calls central server and passes this session ID. All other servers
are signaled that this user as logged into this server(or they could request
each time a user logs onto them). Every time a state is changed its
reflected back and forth. This isn't optimal of course and technically isn't
probably very good but it should work.
That's fine. But the other remote servers won't get the cookie
containing the session id, as noted above.
The main problem, I suppose, is creating a unique ID for the user. Would
have to atleast be the IP but then that causes problems with proxies and
stuff. Maybe there is a way though...
IP won't do it. Many corporations, for instance, have a single IP for
all of their outgoing connections. And that IP, if dynamic, can change
at any time. Also, some corporations (and even ISPs like AOL) use
multiple proxies - and the IP address can change with every request.
I really don't see the issue though. After all you could have two servers
running on the same computer but one listens on a different ip. Surely they
would not have any issues sharing a session? (it might require some new
software to handle it efficiently though) Doing it remotely shouldn't be
that much more of a problem(aside from the security issues).
They sure will - because of security restrictions noted above.
of course I could be missing something but I don't think your reasoning is
valid as its pretty easy to synchronize status.

Jon

Yes, you're missing a lot. Mainly security related. The security is
there for a reason. You might be able to bypass it through clever
programming. But then you open yourself and your customers up to all
kinds of possible hacks.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 11 '07 #13
Samir Chouaieb wrote:
Hello,

I am trying to find a solution to a login mechanism for different
domains on different servers with PHP5.

I have one main domain with the user data and several other domains that
need a login to show data.

I want the user to login only once when he visits any of my domains.

The first idea is had is to use the same session for all domains. Is
this possible?

Any help or hint is appreciated.

Thanks in advance

Best regards
Samir
Hello again,

thanks a lot for all your comments and suggestions.
It is interesting to read submits of experienced people.

I will try to combine several ideas concerning central login mechanism
with secure hand shake.

I will present the results on this forum when i get some.

So "see you" later.
Best Regards
Samir
Jun 12 '07 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Mark C via AccessMonster.com | last post: by
reply views Thread by Saiars | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.