Posted by Jerry Stuckle on 07/01/07 21:54

shimmyshack wrote:
> On Jul 1, 3:32 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> shimmyshack wrote:
>>> On Jun 30, 11:44 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> shimmyshack wrote:
>>>>> On Jun 30, 2:23 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>>> shimmyshack wrote:
>>>>>>> On Jun 30, 2:49 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>>>>> Ben Sehara wrote:
>>>>>>>>> "shimmyshack" <matt.fa...@gmail.com> wrote in message
>>>>>>>>> news:1183047662.340289.205790@m36g2000hse.googlegroups.com...
>>>>>>>>>> On Jun 28, 2:49 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>>>>>>>> Ben Sehara wrote:
>>>>>>>>>>>> Is there any way I can limit the access to my website? I have a site
>>>>>>>>>>>> "A" and
>>>>>>>>>>>> I want to allow access to it only from site "B" login user.
>>>>>>>>>>>> If someone try to access site "A" directory, I want it redirected to
>>>>>>>>>>>> site
>>>>>>>>>>>> "B" for login. After login at site "B", you see the link to site"A".
>>>>>>>>>>>> When
>>>>>>>>>>>> you click it, you see login page for site "A".
>>>>>>>>>>>> Is it possible?
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>> Ben
>>>>>>>>>>> Ben,
>>>>>>>>>>> Not easily. The problem here is if you set a cookie on Site B, it won't
>>>>>>>>>>> be sent to site A.
>>>>>>>>>> Was it you that asked this the other day, it is a solveable problem,
>>>>>>>>>> what capabilities do both servers have, do they have php, does only
>>>>>>>>>> one, which one, does one/both have a database, session support?
>>>>>>>> > No, I don't think it's me. This is the first time to post regarding this
>>>>>>>> > topic.
>>>>>>>> > Site "A" has ASP and site"A", my site, has PHP. Both have database and
>>>>>>>> > session support.
>>>>>>>> > Can I use RSS to accomplish this? It just came up in my mind.
>>>>>>>> > Ben
>>>>>>>> P.S. Please don't top post.
>>>>>>>> --
>>>>>>>> ==================
>>>>>>>> Remove the "x" from my email address
>>>>>>>> Jerry Stuckle
>>>>>>>> JDS Computer Training Corp.
>>>>>>>> jstuck...@attglobal.net
>>>>>>>> ==================
>>>>>>> so let me get this straight,
>>>>>>> if someone tried to access a directory of A (not the whole of site A,
>>>>>>> just a page) and were not logged on at siteB, then they are redirected
>>>>>>> there, then on successful login they are redirected back to site A, to
>>>>>>> the page they were on, and now site A asks them to log on as well.
>>>>>>> user goes to A, site A checks whether it lets the user through, if not
>>>>>>> there it makes the ACTION of the form point to an iframe in the page
>>>>>>> and to a script on siteB, and uses RSA for the form, with B's public
>>>>>>> key in javascript, as well as a ID from siteA which is set in siteA's
>>>>>>> cookie, user logs in, this form is encrypted and posted to siteB, site
>>>>>>> B decrypts using it's private key, accepts if user gets it right and
>>>>>>> makes a cURL session to a script on siteA, sending it the ID, which A
>>>>>>> stores in database, id->"redirect=no" then it sends back javascript,
>>>>>>> parent.location.reload(), to force the page on siteA to reload, now
>>>>>>> site A checks whether user with this session needs to be refreshed,
>>>>>>> and id is ok, sent from B, so A prints the login form for A with
>>>>>>> ACTION pointing to a script on A, or just shows A's data.
>>>>>> Who said anything about all this crap?
>>>>>> From what I understand what the user wants, if someone is signed into
>>>>>> site A, they can access anything on Site B.
>>>>> thats not what the OP said
>>>>>> I suspect the entire idea is to not have to sign into both sites.
>>>>> clarification was needed (its why I asked)since thats not what the OP
>>>>> said
>>>>>> If they try to access a page at Site B but don't have the authority,
>>>>>> they are redirected to Site A for sign in. Once signing in, they can
>>>>>> access the page on Site B.
>>>>> If someone try to access site "A" directory, I want it redirected to
>>>>> site
>>>>> "B" for login. After login at site "B", you see the link to site"A".
>>>>> When
>>>>> you click it, you see login page for site "A".
>>>>> it reminds me of stealing credentials - using xss, dont know whats on
>>>>> the OPs mind really,
>>>>> it can be done without encryption, sure - I was having fun, lets see
>>>>> what the users problem actually is
>>>>>> As for the rest - what a complicated way of handling things.
>>>>>> --
>>>>> hardly! just form, some js, and a couple of scripts! not quantum
>>>>> physics this stuff!
>>>>> overcomplicated sure, this isnt a hard problem, but whats wrong with
>>>>> having a little fun, just a quick server-server connection, together
>>>>> with sessions, but the method used above will work whatever the user
>>>>> wants
>>>>>> ==================
>>>>>> Remove the "x" from my email address
>>>>>> Jerry Stuckle
>>>>>> JDS Computer Training Corp.
>>>>>> jstuck...@attglobal.net
>>>>>> ==================
>>>> And among other things, requires JS.
>>>> But yes, I consider it quite complicated - lots of things which can go
>>>> wrong!
>>>> --
>>>> ==================
>>>> Remove the "x" from my email address
>>>> Jerry Stuckle
>>>> JDS Computer Training Corp.
>>>> jstuck...@attglobal.net
>>>> ==================
>>> session stuff is standard and trusted, db the same, form posting the
>>> same, as for requiring js, thats just to keep things secure, dont /
>>> have/ to. The only extra step over and above any other method is the
>>> rsa, standard implementation once again, reliable and fast, the
>>> problems as usual would be on the wire, which we are all used coding
>>> for.
>> Still needlessly complicated. Won't work for the estimated 10-15% that
>> have JS disabled, and all kinds of possibilities for other
>> communications between the two systems to fail.
>>
>> A kludge just waiting to break. Much easier would be for the two to
>> have a shared database.
>>
>> Alternatively, a one-time hash can be used - for instance, take a number
>> which increments every time, or the current date and a sequential
>> number. Embed the number in a predefined string and take the MD5 hash
>> of the resulting string. On the receiving end, validate the hash (same
>> algorithm) and start the session. Each has can only be used once.
>>
>> Or any of a number of ways much simpler than yours.
>>
> as previously stated, js isnt required, i was just having fun, and as
> for it being a kludge, as you put it, I have being using js rsa for
> ages, it's just a standard implementation - maths - works everytime,
> but of course you need js! just as crypto on php works everytime but
> you need php!
> as for there being any number of alernative ways...(?)... the core of
> my way is server-to-server com - what you will have to do at some
> point, and a form. how is my way more complicated? oh yeah optional
> js!
>
>

(Top posting fixed)

Which is it - do you need js or don't you? As for whether you need it
or not - you have control over the server and PHP implementation. You
have *no* control over the client and what they have installed.

So you can always guarantee crypt() and other php function work - but
you can never guarantee anything related to js works.

As I said - yours takes a lot of programming and is needlessly
complicated. There are many simpler ways, of which I indicated two.

And please don't top post.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]