[Design] [cosmo] [proposal] [last call] Sign up for an account + adding the currently viewed collection

[Matthew Eernisse]

Comments belooooo ... :)

Travis Vachon wrote:
> There are actually a couple different ways we could implement this one:
> 
> a) Add subscription information to the CMP data model, so that we could 
> create users with subscriptions in one step.
> 
> I don't like this, and I know Brian didn't like it when I proposed it, 
> as it mixes up our data models. Information about content is not 
> currently part of CMP, and it would be a pretty big departure from the 
> protocol to do this. That said, I'm open to discussing it.

This doesn't sound like the right approach, no.

> b) Punch a hole in our security to allow subscriptions to be added to 
> unactivated accounts. This could be done by:
> 
> i) Building a special exception for certain operations into the method 
> that decides whether or not a user is activated (and thus whether or not 
> a client can authenticate as the given user). This seems really crufty 
> and ugly, building information about our protocols into our auth code.

The fact of the account being activated or not doesn't seem to me like 
protocol information. Now that we have added account activation, it 
means that there are actually two different logical levels of account 
access now:

1. activated -- full access to the application
2. not-yet-activated -- limited access (can only pre-add subscriptions)

We can certainly auth a user based on just login ID and password -- we 
know they have a valid account in the system, even if it hasn't been 
activated yet.

How is checking for an 'activated' flag in the account any different 
from checking for an 'administrator' flag to limit access to certain 
functionality?

> ii) Allow anonymous clients to add a subscription to a user. This is 
> definitely a security hole. Spammer add bogus advertising subscriptions 
> to arbitrary calendars, Cosmo becomes object of ridicule. Out of the 
> question in my mind.

Yep. That would just be very silly.

>> The bottom line would be that we can't assume the process would always 
>> work, and end-users in those cases would be left wondering why it 
>> didn't "add this
>> subscription" like it said it would.
> 
> Agreed, I don't like this either.

Yes, in this case I really don't thihnk something that only Mostly Works 
is good enough.

> Remember, account activation is optional, so this would only solve half 
> the problem (the whole problem for Hub, since it uses account 
> activation). We could have separate logic for the non-account-activation 
> scenario, but that seems overly complicated

Yes, that's what I was envisioning we'd have to do -- for 
non-account-activation, it would actually just make another service call 
to add the subscription right there. But maintaining branched code for 
that is indeed ugly, and seems needlessly complicated.

> 4. Use the preferences system to implement this feature.
> 
> Thoughts?

As you mention in your next e-mail, this has the same auth problem that 
simply adding the subscription would have. If we could do this, we could 
just add the subscription right there.


Matthew