On Wed, Feb 16, 2005 at 10:54:58AM +1100, Taryn East wrote: > * 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?
Setting a cookie to be read by another site is trivial, and is standard practice at a lot of sites -- the f2 network (smh.com.au, theage.com.au, and all the rest of those f**kwits) do it all the time. There are settings in Firefox to deny the setting of cookies for another site, but even I, the Cookie Nazi, don't have that option turned on. > > 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... If you're going to do it, you might as well do it properly. > 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... The channel partner has their public key, they use that to crypt up something and hand the crypted string in a cookie to the web browser, which then presents the crypted string to *your* site, which decrypts using the private key, and if everything works out you permit access to the browser and increment the channel partner's statistics. > 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. Indeed. Which is why the user has to go to their site to login and receive a cookie to permit them entry into your site. > 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"). Blergh. Form-based auth is more "flexible" to some degree, but it's always seemed a bit wasteful to me, considering that HTTP comes with an auth mechanism already... > > 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... It's quite simple. You create a page on your site, like so: http://www.yoursite.com/incoming.cgi Which gets passed a couple of parameters, like so: /incoming.cgi?token=xyzzyxyzzyxyzzy&loc=/page/you/want/to/go/to.html Your site takes the token information as an "instead of" for the cookie, verifies it (using any one of the methods above), and then, if it all matches, sets a local cookie and sends a Location: /page/you/want/to/go/to.html header to redirect the user to the page they really wanted to view. So, your channel partners need to rewrite all URLs that point to your site in the form above, probably with a dynamically generated token= field, so you can do the cookie management yourself. In case you're still hung up on HTTP auth, I'll state things very cleanly: there is *no* *way* for you to do what you want using plain HTTP authentication on your site. There are only two ways to send HTTP auth info to the web server -- by plain-texting the credentials into the URL, or having the user type them by hand. You *will* need to implement some alternative means for your channel partners to hand off users from them to you. > > > 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... Well, you could, kinda, by using the incoming.cgi answer with a per-channel-partner-but-static token= field, but sooner or later your users are likely to figure that one out and start bookmarking your incoming.cgi instead... - Matt
signature.asc
Description: Digital signature
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
