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

[Travis Vachon]

>
> In the previous discussions about how to do this, there were a  
> three possible approaches we discussed:
>
> 1. Adding the subscription on the server-side after the account is  
> created, but before it's activated.
>
> The benefits of this approach are obvious -- the subscription is  
> added to the account right away, and nothing can happen in between  
> creating the account, getting the e-mail, and verifying/activating  
> the account that would cause the subscription to be lost.
>
> IIRC, the major downside of this approach is that it was deemed to  
> be difficult to implement because of the inflexibility of our  
> security model. (I believe there were also concerns that allowing  
> subscriptions to be added to a not-yet-activated account could be a  
> security risk, which seemed a little dubious to me.)

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.

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.

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.

Any other ideas?

>
> 2. Storing the information about a 'subscription to be added' in a  
> browser cookie, and adding the subscription after the user actually  
> logs on to the new account.
>
> The benefit of this approach is that it doesn't require any server- 
> side work.
>
> The downside is the inherent unreliability of cookies. For example,  
> if the users completes the account-activation process from a  
> different browser (e.g., goes home from work and checks e-mail  
> there), the subscription will not get added to their account.
>
> 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.

>
> 3. Change the activation e-mail to include information about the  
> desired subscription, and put it into the URL for the confirmation  
> page.
>
> The benefit is that approach is that the info for the subscription  
> is in the actual e-mail, so it comes along with the users to the  
> activation and login pages -- no matter where they log in to the  
> app from.
>
> The only drawback I can think of is that it would require some  
> amount of server-side work. There may be others. I would appreciate  
> feedback from Travis on this.
>

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

4. Use the preferences system to implement this feature.

We built out a system for storing arbitrary key-value pairs on the  
server side to implement preferences, couldn't we use this instead of  
a cookie to implement option 2?

The one downside is an extra server call, but we could have the code  
only check for a pending subscription the first time a user logs in.  
We already do this to add a default calendar to a user's account, so  
that would probably be a reasonable location for this logic. This  
would mean the Web UI performs a check for pending subscriptions any  
time the user has no calendars, but I think that's a pretty minimal  
cost.

Thoughts?

>> I believe we had a discussion on the list to see if it was  
>> necessary to keep the out of the box 'Chandler Hub' calendar. I  
>> think for now, I don't see much harm to keep a blank calendar for  
>> the CC users. When we introduce remove, perhaps they would be able  
>> to remove it from their list?
>> Any thoughts on this proposal?
>> -Priscilla
>
> I think it's a good idea anyway to give CC users their own empty  
> calendar in the Web UI. It's a way of encouraging them to try it  
> out themselves.

+1, especially since there is currently no mechanism for adding  
calendars.


-Travis