On 12/10/05, Jeff Watkins <[EMAIL PROTECTED]> wrote: > Frankly, I don't like the disjoint users idea. I'd rather look at a > single-sign-on style solution. Maybe with a cross provider credentialing > scheme. I'll give this some thought in the next few days, but I *am* a > little distracted right now: > <http://newburyportion.com/2005/12/molly-elizabeth-watkins>. >
I agree. In 99% of cases I would say that this is the right way to go about things. Let me explain about my app a little and how I would see it working. Basically the app is to prevent huge files from being transmitted via email. Most if not all of my users cannot and will not fathom things like FTP/SCP to transfer the files, so I'm writing a web based app that allows them to easily upload files to the server. The server then generates a "reciept" which they paste into their emails. This reciept has a link (or links if they uploaded more than one file) which the person at the other end can use to collect their file. On the pickup page I don't want anyone to be able to just stick a random url in with the chance of downloading the file, so each file has a recipient attached to it in the database. The seperate login that I need is for that recipient confirmation and the only field needed is their email address, no password. The "pickup" controller doesn't need to know anything at all about any of the other identities. It just needs to know that the person trying to download the file in question is in fact the intended recipient. As it is I've already started rolling my own for the recipient confirmation as there were too many things that would have prevented the identity framework from being used, and hacking the framework in such ugly ways didn't appeal to me at all and seemed like more work. As I said, this is not quite a normal use case as, for the most part, you'd want to have a unified login with two providers. Lee
