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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
