On 9/18/07, Mimi Yin <[EMAIL PROTECTED]> 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 sharing. 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 details. 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. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
