ok, reading this has made me suspect my knowledge of cookies is much less
complete than I had at first thought...
I'm just going to ask a whole bunch more questions and hopefully nut out
the answers...
* Matthew Palmer <[EMAIL PROTECTED]> spake thus:
> There's lots of things that can be done with cookies:
>
> The bog-basic way -- have the channel partner set a cookie for your site
> containing info on them. Maybe base64 encode it to keep out the casual
> poker.
this would be ok for the channel partners logging into our site, but
wouldn't clients of the channel partner have issues with the cookies
being for the channel-partner site? how would their site set a cookie
for our site such that someone logging into their site can then get
into ours?
> The hyper-secure option -- Provide each of your channel partners with the
> public portion of an asymmetric key, with which they encrypt the contents of
> the cookie, typically a unique ID of some sort, of perhaps other useful
> info. Your site then decrypts the cookie with the private portion of the
> key, and (assuming everything matches) grants appropriate access. Use
> asymmetric rather than symmetric so that insecurity at the other sites won't
> screw *you* over, and use a different key pair for each channel partner so
> that you can prove which partner provided the referral.
this seems to be a way of securing the above... which is nice, but
probably OTT given that I know how dodgy security is already on our
site... while I'm trying to persuade them to change this, I may not be
able to do it on this project (especially as I'm the "junior" programmer
and the "senior" programmer is much more into "it's just easier this
way"... but I'm not bitter ;))
anyway, as I can see, the above raises the same questions for me as the
previous one - I'm not sure how we can then get this onto the
channel-partner's clients without having to hand each of them the key...
and I get the feeling this is similar to just handing them the login
details.
To clarify, I think the business perspective here is that the channel
partners don't want their clients realising that they can just come to
our site by themselves without having to use the CP sites... they don't
want the middlemen (ie themselves) cut out :) So they don't want the
clients knowing that there is any other login even involved.
> The WS option -- Have the channel partner generate a unique ID and send it
> to your site via some sort of basic SOAP interface, and hand the same ID (or
> derivative) to the user in a cookie set for your site.
this sounds interesting and probably the better option in the long run -
but this also sounds like we would have to alter how we currently do
logins (currently via http authentication rather than SOAP options)
which is unlikely to be scoped into the current project. :(
It's probably a good idea for our "next generation project", though. I
hear they're planning on changing over to "form based authentication"...
which to me means nothing and I haven't heard anything more about it
apart from just that, even after asking (I think I got some vague waffle
about it being "just better").
> Alternately, the channel partners could have individual portal pages which
> they point their users to, which you then set cookies or whatever to
> identify the visitor and they get redirected to the right place.
by individual do you mean a different page for each user? Probably not a
good idea - I think they like their generic pages and I can understand
why. Otherwise I think I'm just confused...
> > ok, now they aparrently used to do this by having a url with the
> > username/password in it (ie using "basic" http authentication with the
> > login details as parameters).
>
> Eeeeeeew. Why bother even *having* logins if they're going to send them to
> anyone that asks for them?
yep, that's my reaction... again, I'm just a junior - what would I know
;)
I guess they like the impression of being secure without actually
putting all that "hard work and effort" that it'd obviously take to fix
it (not). <sigh>
But then, this is business for you and I am just not surprised anymore.
> > There is a hell of a lot on the web on autologin functions from the
> > recipient side fo things (ie the one receiving the login details) but we
> > need some code to hand to our channel partners that can run on their
> > server to send the login details to us... something that can be
>
> Details of the partners' sites? If you're going to write it for them,
> unless they're all using the same environment and roughly the same websites,
> you're not going to be able to send them a one-size-fits-all bit of code.
yes I know and I have informed my manager of this - he didn't realise it
and hoped that it could all be done at our end... he was hoping we could
just hand them a URL-solution like it was before...
Anyway, I've convinced him that we can only offer possible solutions -
and he has asked me to write a demo area that we can show to CPs. The
PHP solution of CURL ofered in another thread sounds like a good one
because a lot of people can easily run PHP. A cookie solution would be
nice too as that is doable on pretty much all systems. Proprietary
solutions are less useful because we have no way of convincing people to
change over to such systems... and I wouldn't want to either.
anyway, thanks for your help so far :)
Taryn
--
This .sig temporarily out-of-order.
We apologise for any inconvenience
- The Management
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
