|
|
Posted by Jerry Stuckle on 06/11/07 17:28
Jon Slaughter wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:VpidneEtRqdVIPHbnZ2dnUVZ_r_inZ2d@comcast.com...
>> Jon Slaughter wrote:
>>> "Samir Chouaieb" <chouaieb@nospam.arcor.de> wrote in message
>>> news:466bdf44$0$20300$9b4e6d93@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.
>
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.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|