On Wed, Sep 14, 2011 at 10:51 PM, Joshua Paine wrote:
> FTR, I'm not suggesting changing fossil's web ui, just suggesting the
>
A related point: once the JSON login is working we could actually run the
login from the UI in AJAX mode, as opposed to a separate request. We should
be able to incremen
On Wed, Sep 14, 2011 at 10:51 PM, Joshua Paine wrote:
> FTR, I'm not suggesting changing fossil's web ui, just suggesting the
> HTTP Basic Auth would be the easiest thing for clients of a JSON API.
>
i'm working on all that right this moment, as a matter of fact.
> Seems like this unfortunately
On 9/14/2011 4:36 PM, Richard Hipp wrote:
Fossil honors the REMOTE_USER environment variable in CGI mode, so
you can use Fossil with Basic Auth.
How quickly I forget...
FTR, I'm not suggesting changing fossil's web ui, just suggesting the
HTTP Basic Auth would be the easiest thing for clients
On 14 Sep 2011, at 21:36, Richard Hipp wrote:
>
>
> On Wed, Sep 14, 2011 at 4:30 PM, Joshua Paine wrote:
> On 9/14/2011 4:22 PM, Ben Summers wrote:
>>> HTTP basic authentication is widely supported in HTTP client
>>> libraries, and much less hassle to use than passing tokens around.
>>>
>> Th
On Wed, Sep 14, 2011 at 4:30 PM, Joshua Paine wrote:
> On 9/14/2011 4:22 PM, Ben Summers wrote:
>
>> HTTP basic authentication is widely supported in HTTP client
>> libraries, and much less hassle to use than passing tokens around.
>>
>
> The three major downsides with HTTP Basic Auth are:
>
> 1)
On Wed, Sep 14, 2011 at 10:22 PM, Ben Summers wrote:
> HTTP basic authentication is widely supported in HTTP client libraries, and
> much less hassle to use than passing tokens around.
>
Supporting that is certainly on the list of things to do.
i'm currently still ironing out how to internally
On 9/14/2011 4:22 PM, Ben Summers wrote:
HTTP basic authentication is widely supported in HTTP client
libraries, and much less hassle to use than passing tokens around.
The three major downsides with HTTP Basic Auth are:
1) No pretty login page
2) No reliable way to logout in most browsers
3)
On 14 Sep 2011, at 18:26, Stephan Beal wrote:
> On Wed, Sep 14, 2011 at 7:24 PM, Stephan Beal wrote:
>> No, but for supporting clients which don't have cookies support. e.g. i've
>> written Java HTTP client apps (using a similar API to this one, actually)
>> but the client code doesn't support
On Wed, Sep 14, 2011 at 8:30 PM, Richard Hipp wrote:
> To clarify, Fossil uses a single namespace to hold all environment
> variables, ...parameter. They all work the same.
>
That's a bonus for me, actually. i'm currently digging around in
login_check_credentials() and friends to figure out whe
On Wed, Sep 14, 2011 at 2:20 PM, Stephan Beal wrote:
> On Wed, Sep 14, 2011 at 8:05 PM, Richard Hipp wrote:
>
>> cgi_set_parameter("fossil-ABCDEF", "xx");
>>
>
> Great :). i now see cgi_replace_parameter(), which is what i really want
> (because the JSON auth info will be processed after fos
On Wed, Sep 14, 2011 at 8:05 PM, Richard Hipp wrote:
> cgi_set_parameter("fossil-ABCDEF", "xx");
>
Great :). i now see cgi_replace_parameter(), which is what i really want
(because the JSON auth info will be processed after fossil has done its
cookie cutting).
Thanks!
--
- stephan bea
On Wed, Sep 14, 2011 at 1:42 PM, Stephan Beal wrote:
> On Wed, Sep 14, 2011 at 7:36 PM, Richard Hipp wrote:
>
>> I'm thinking you don't need to change or enhance any of this for JSON.
>>
>
> Thank you for the very detailed response. It sounds like i'll have to touch
> less code than i was expect
On Wed, Sep 14, 2011 at 7:36 PM, Richard Hipp wrote:
> I'm thinking you don't need to change or enhance any of this for JSON.
>
Thank you for the very detailed response. It sounds like i'll have to touch
less code than i was expecting, but i think the one place i need to change
would be a way to
On Wed, Sep 14, 2011 at 12:27 PM, Stephan Beal wrote:
> Hello, anyone who's intimate with fossil's authentication code...
>
> i've decided not to punt the authentication problem (now moving it to the
> start of the TODO list) because authentication levels end up changing the
> output generated by
On Wed, Sep 14, 2011 at 7:24 PM, Stephan Beal wrote:
> No, but for supporting clients which don't have cookies support. e.g. i've
> written Java HTTP client apps (using a similar API to this one, actually)
> but the client code doesn't support cookies, so it has to pass around its
> authenticatio
On Wed, Sep 14, 2011 at 7:15 PM, Ron Wilson wrote:
> Are you proposing supporting non-HTTP transport of JSON client-server
> interaction?
>
No, but for supporting clients which don't have cookies support. e.g. i've
written Java HTTP client apps (using a similar API to this one, actually)
but the
On Wed, Sep 14, 2011 at 12:27 PM, Stephan Beal wrote:
> b) For non-login JSON requests, first check the request info (GET/POST) for
> an authorization token. If found, i need to be able to tell fossil, "here's
> your cookie - use this one." i.e. i need to be able to make fossil think it
> got a co
Hello, anyone who's intimate with fossil's authentication code...
i've decided not to punt the authentication problem (now moving it to the
start of the TODO list) because authentication levels end up changing the
output generated by some requests (e.g. whether or not links are generated
from comm
18 matches
Mail list logo
