[Design] Re: [Cosmo] Reconciling various sharing URLs
bcm at osafoundation.org
Wed Sep 19 10:30:51 PDT 2007
On 9/18/07, Mimi Yin <mimi at osafoundation.org> wrote:
> Can we take a ticket URL and if the user is already logged in and/or
> when the user logs in, can we redirect the ticket URL to the /mc/ URL
> so that the user sees not the ticket view for the collection, but the
> logged-in-from-their-account view of the collection?
yes: if the user is logged into the web ui, when the user goes to the
ticket view of a collection, the web ui theoretically can detect that
the user is logged in and redirect the user to the logged-in view of
the collection. essentially your browser's location bar would be
redirected from /pim/collection/deadbeef?ticket=foobar to
/pim/collection/deadbeef. i think the changes to do this would be
pretty simple, but the ui guys would have to confirm this.
> On the desktop can we take a ticket URL and the user's Chandler Hub
> account and under the hood, redirect the subscription from the ticket
> URL to the /mc/ URL.
short answer: yes, but with qualifications.
long answer: first i want to clear up the terms "ticket url" and "mc
url" and what all that means. there are two different dimensions -
which part of the server the url identifies (the web ui, which is
prefixed at /pim, and the sharing service, which is prefixed at /mc);
and which type of authentication to use (basic, which doesn't look in
the url for a credential but rather calls back to the client to ask
directly for username and password, and ticket, which looks in the url
for a ticket and doesn't know anything about usernames and passwords).
considering these two dimensions, there are 4 combinations leading to
possible urls for a particular collection:
1- pim url without ticket (/pim/collection/deadbeef) - since there is
no ticket, if you plug this into your browser, you'll get the login
page. after logging in, you go to the logged-in view with your default
calendar selected. you need to enter username and password to proceed.
this is not designed for non-browser clients. this url cannot be
meaningfully bookmarked in a browser unless we enhance the web ui to
redirect you to the logged-in view with the deadbeef calendar selected
after you log in.
2- pim url with ticket (/pim/collection/deadbeef?ticket=foobar) -
since there's a ticket, the web ui can show you the ticket view of
this collection. presumably if you already used the login form to log
into the web ui at some previous point, the web ui can redirect you to
the logged-in view with the deadbeef calendar selected. this url can
be meaningfully bookmarked in a browser. ALSO, chandler can use this
url to look up the mc url with ticket (see #4 below) to use for
3- mc url without ticket (/mc/collection/deadbeef) - used by chandler
for sharing through morse code. since there's no ticket, the server
will prompt for username and password using the http "basic"
authentication scheme which causes chandler to use your account
4- mc url with ticket (/mc/collection/deadbeef?ticket=foobar) - used
by chandler for sharing through morse code. since there's a ticket,
the server doesn't have to ask for username and password.
so if we go back to the problem that caused this thread in the first
place: when you're logged into the web ui, and you want to get the
"chandler sharing" url for a collection, what you get is the mc url
without ticket (#3 above). if you just hold your breath and have faith
that this thing is going to work and you go plug into the desktop's
subscribe dialog, the desktop will have to use the username and
password set up for your account, and sharing will succeed.
but oh no, that's a mc url, which looks slightly different than 1) the
pim url with ticket (#2 above) that the desktop gives you as the
"chandler sharing" url and 2) the same pim url with ticket that the
web ui would give you if you were looking at the web ui in ticket view
rather than logged-in view.
i disagree that this is confusing - how many regular non-geek people
actually try to understand what the components of a url signify? - but
as a thought exercise, i'll accept that it is to somebody.
for the case where i am trying to subscribe to my own collection from
another instance of desktop than the one where i originally published
the collection, i want the server to always know that it's me changing
and deleting stuff in the collection, as opposed to some anonymous
person hiding behind a ticket, so i always want the desktop to be
sending my username and password to the server. therefore, i want the
desktop using a mc url without ticket (#3 above) rather than a mc url
with a ticket (#4). but it's too confusing for the web ui to give me
the ticketless mc url. so we've only urls #1 and #2 are still in the
running as urls that i can take from the web ui and plug into desktop.
option A: web ui gives me the ticketless pim url (#1). i plug it into
desktop. desktop recognizes that since there is no ticket, it can't go
fetch the web page at the pim url since the response is just the web
login page. so it applies some rule to transform the ticketless pim
url into the equivalent ticketless mc url. is it possible to formulate
such a transformation rule that doesn't make too many assumptions
about how the server constructs its urls? not really. the safest
assumption the desktop can make is that the "collection/deadbeef" part
of the url won't change and that it can just be tacked onto the "/mc"
part. the desktop can find the "/mc" part, including the scheme, host,
port and context path by using grabbing it from the cmp user service
document, which the desktop already knows how to get. this option
sucks a little because of this assumption.
option B: web ui gives me a ticketed pim url (#2). i plug it into
desktop, which uses it to get the ticket-view web page and parse out
the corresponding ticketed mc url. it then drops the ticket from the
mc url and uses the now-ticketless mc url to subscribe. on the surface
this seems fine, but it raises all those questions i brought up
earlier in the thread about which ticket the web ui chooses to
construct the ticketed pim url. it could just pick one at random,
since it has no idea which one wa created by chandler. or we could
limit items to only having one ticket of each type. this option is not
terrible if we do add the single-ticket-per-type limitation, but it's
kind of cheesy if the web ui just picks a ticket at random. it also
feels a little cheesy to have the desktop just drop the ticket from
the mc url, but at least it has a spec to go by (the ticket spec says
the ticket is represented by the ticket query parameter, and the
server isn't ever going to change that unless the spec changes).
now, in the real world, if i'm setting up a second instance of
desktop, i'd prefer it to automatically detect all of my published
collections when i set up my server account info. that way i would
never need to go to the web ui to get any sharing urls in the first
place. that would make this whole problem go away. there would be no
reason to offer chandler desktop as a "subscribe with" option in the
logged-in view of a collection in the web ui.
but if we can't live in the real world, then i suppose i'd prefer
option B - web ui provides a ticketed pim url, desktop uses that to
find the ticketed mc url and then drops the ticket from the mc url.
ideally we'd add the single-ticket limitation so the web ui doesn't
have to make any choices about which ticket to use, but if we can't do
that either, then the web ui could choose the first ticket with read
privilege it finds for the item.
More information about the Design