Re: WebObjects, just-in-time login and SSL
Re: WebObjects, just-in-time login and SSL
- Subject: Re: WebObjects, just-in-time login and SSL
- From: Mark Wardle <email@hidden>
- Date: Fri, 15 Apr 2011 19:45:16 +0100
Ps that page is great. I can't believe I didn't know it's existence!
Mark
--
Dr. Mark Wardle
Specialist registrar, Neurology
(Sent from my mobile)
On 15 Apr 2011, at 19:31, Mark Wardle <email@hidden> wrote:
> Thanks Chuck
>
> Mark
>
> --
> Dr. Mark Wardle
> Specialist registrar, Neurology
> (Sent from my mobile)
>
>
> On 15 Apr 2011, at 18:29, Chuck Hill <email@hidden> wrote:
>
>>
>> On Apr 14, 2011, at 2:52 PM, Mark Wardle wrote:
>>
>>> Hi there.
>>>
>>> I now have a [almost] working system that checks a system property and
>>> conditionally forces the use of https for relevant resources.
>>>
>>> There is some hostname flakiness going on which messes with cookies
>>> (switching between localhost and Daisy.local) which is odd.
>>
>> Check the other app properties that your are or could be setting:
>> http://developer.apple.com/legacy/mac/library/#documentation/WebObjects/WOAppProperties/Articles/ApplicationProperties.html#//apple_ref/doc/uid/TP40005337-SW1
>>
>> Specifically, WOCGIAdaptorURL. These should all use the same host. I would avoid using Daisy.local.
>>
>>
>>> The main reason why the hostname keeps getting changed in my use of
>>> ERXNavigationMenu and specifically the way it generates URLs for
>>> direct actions. These seem to insist on being full URLs (and hence
>>> change the hostname) although this somewhat depends on whether I'm
>>> switch from storing sessions in a cookie or URL. Whatever the case,
>>> despite the navigation buttons being rendered on a https page, the
>>> link goes to http:// I note any component actions simply use a
>>> relative URL and stay as https:// and exhibit no hostname flakiness.
>>>
>>> I'm ready the relevant wiki pages on SSL and specifically setting the
>>> hostname to localhost specifically in all the relevant configuration
>>> files.
>>>
>>> My naive assessment of this is that within
>>> ERXNavigationMenuItem.contextComponentActionURL() should be fixed to
>>> default to the current setup:
>>>
>>> change
>>>
>>> return context().directActionURLForActionNamed(navigationItem().directActionName(),
>>> bindings);
>>>
>>> to
>>>
>>> return context().directActionURLForActionNamed(navigationItem().directActionName(),
>>> bindings, ERXRequest.isRequestSecure(context().request()), false);
>>>
>>>
>>> Or is this wrong?
>>
>> That seems like a reasonable thing to try. I am not currently using this component.
>>
>>
>> Chuck
>>
>> --
>> Chuck Hill Senior Consultant / VP Development
>>
>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden