accessing https URLS with basic authentification

[Ben Rubinstein]

On 8/5/09 12:42, Paul Williams wrote:
> Don't forget only Rev Enterprise supports https.

On 8/5/09 12:24, Bernard Devlin wrote:
 > Basic Auth should still work with https.
 >
 > I think the problem might be to do with the verification of the SSL
 > certificate.  Try running this before you make your https URL call:
 >
 > libUrlSetSSLVerification false

Thanks both for your replies.  I am using Enterprise, and can retrieve https 
from a site not requiring basic auth fine.

I've tried Bernard's suggestion of libUrlSetSSLVerification (btw I notice that 
there's no documentation for this command - Bernard can I ask where you found 
out about it?) - however the setting of this seems to make no difference.

As noted, curl is fine (as is Firefox).

Normally in this sort of situation, I can watch the network traffic to pin 
down the difference between the exchange that works and the (Rev) exchange 
that doesn't - but in this case it's a load of encrypted stuff!  All I can see 
is the pattern of blocks, as below - but as I don't know anything about the 
https protocol, I don't understand its significance, if any.  Does it indicate 
that Rev has missed out a step?  Or that Rev has in somehow encoded the 
authorisation in a way that the server doesn't like, hence the final block in 
the conversation with Rev is an 'unauthorised, please go away', while the 
conversation with curl starts to deliver the actual data?

             Rev                         curl
             ---                         ----
             client:  0 bytes            client:  0 bytes
             server:  0 bytes            server:  0 bytes
             client:  0 bytes            client:  0 bytes
             client:  118 bytes          client:  102 bytes

             server:  0 bytes            server:  0 bytes
             server:  1368 bytes         server:  1368 bytes
             server:  1368 bytes         server:  1368 bytes

             client:  0 bytes            client:  0 bytes
             server:  1368 bytes         server:  1368 bytes
             client:  0 bytes            server:  935 bytes
             server:  935 bytes          client:  0 bytes
             client:  0 bytes

             client:  198 bytes          client:  198 bytes
             server:  59 bytes           server:  59 bytes
             client:  0 bytes            client:  0 bytes

             client:  218 bytes          client:  277 bytes
             server:  0 bytes            client:  277 bytes
             server:  554 bytes          server:  0 bytes
             client:  0 bytes            server:  1368 bytes
                                         server:  1368 bytes
                                         server:  10 bytes
                                         client:  0 bytes
                                         client:  0 bytes
                                         client:  37 bytes
                                         client:  0 bytes
                                         server:  0 bytes
                                         server:  37 bytes
                                         client:  0 bytes
                                         server:  0 bytes
                                         client:  0 bytes
                                         server:  0 bytes
                                         client:  0 bytes


I also no longer seem to be able to step into libURL code in the debugger - is 
this something we lost in the 3.0 rollout?

Any further suggestions gratefully received...

Ben

>> On Fri, May 8, 2009 at 12:43 AM, Ben Rubinstein <benr_mc at cogapp.com>
>> wrote:
>>> I can load an "https" URL fine.
>>>
>>> I can load an "http" URL protected using 'basic' authentification,
>> using
>>> either the "http://user:password@www.somewhere.com/" format, or by
>> using the
>>> HTTPHeaders property to explicitly add an "Authorization: Basic
>> xxx" header.
>>> But I can't load an "https" URL that's protected using basic
>>> authentification, using either of the methods described above.
>>>
>>> Is this a known problem?  Can anyone else either reproduce this
>> problem, or
>>> alternatively confirm that they _can_ load such a URL?
>>>
>>> (NB1 this is on Mac OS X, Rev 3.0 and 3.5.)
>>>
>>> (NB2 I can retrieve the URL fine using "curl" in the terminal -
>> and in fact
>>> for now I'm working around the problem by using shell() to invoke
>> curl.  But
>>> I really want to handle URLs of this form in the same way I'm
>> handling other
>>> http URLs in my app, which give me more control.)
>>>
>>> Any insights gratefully received,
>>>
>>> TIA
>>>
>>> Ben