[Design] [cosmo] [proposal] [last call] Sign up for an account
+ adding the currently viewed collection
travis at osafoundation.org
Tue Apr 10 10:11:13 PDT 2007
> 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
> 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
>> 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?
> 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
More information about the Design