[Chandler-dev] Re: [Cosmo-dev] Re: [Dev] Re: [Cosmo] Apple iCal & cosmo-demo

[Oren Sreebny]

I think the real issue here is whether or not people will be passing  
their passwords over the web in clear-text.

- Oren

On Mar 15, 2006, at 1:14 PM, Mimi Yin wrote:

> Just to clarify:
>
> Is it a security boo-boo to have the HTTP port open at all on cosmo- 
> demo? Or is it only a security risk once you've handed out the HTTP  
> URL/ticket?
>
> What I'm getting at is: Can we leave it up to the user to decide  
> whether they want to share with iCal users bad enough that they  
> don't care about doing it via a secure port? (It is our single  
> usable/testable interop scenario and probably will be for a while.)
>
> For people downloading Cosmo and running their own instance, we can  
> document what we've done in the client so they understand that if  
> they don't make the HTTP port available, the iCal URL Chandler  
> spits out won't work.
>
> I think it makes more sense to place the burden of reading  
> documentation on the admin-type user who's downloading Cosmo than  
> to place that burden on the Chandler end-user. (We had a hard  
> enough time getting people to read the chandler landing page ;o)
>
> Mimi
>
> On Mar 15, 2006, at 12:34 PM, Morgen Sagen wrote:
>
>>
>> On Mar 15, 2006, at 12:14 PM, Brian Moseley wrote:
>>
>>> On 3/15/06, Sheila Mooney <sheila at osafoundation.org> wrote:
>>>> So it looks like either of these options aren't great. Are there  
>>>> any
>>>> others we should be considering (other than punting on this use  
>>>> case
>>>> altogether)?
>>>
>>> for cosmo-demo: i think we should allow both cleartext and secure
>>> access, and prominently document ical's behavior on the cosmo-demo
>>> front page so that cosmo users know to not use https.
>>>
>>> for cosmo itself: i don't think we should make any code changes. at
>>> some point apple will resolve their issue and reintroduce ssl  
>>> support
>>> into ical. at that point any ical-specific code we've written will
>>> become useless until we refine it to recognize specific versions of
>>> ical (assuming that's even possible). don't want to go there.
>>
>> I agree that we should just document how to get around iCal's  
>> current behavior.  Otherwise we would have to add code to Chandler  
>> equivalent to:
>>
>>  "if we've just published a collection to this specific host  
>> (cosmo-demo.osafoundation.org) over port 443, then return three  
>> URLs ***, otherwise return two **."
>>
>> I don't see any other technical solution that doesn't require  
>> Cosmo to communicate the fact that there happens to be another  
>> port open that points to the same instance.  Let's just document  
>> this and move on.  There are more important issues to deal with.  :-)
>>
>> ~morgen
>>
>> *** Three URLs: an https/read-write, an https/read-only, and a  
>> http/read-only
>> ** Two URLs: a read/write and a read/only, using whatever port was  
>> used for publishing
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev