Re: [fossil-users] JSON login demo: is this interface acceptable?
On Fri, Sep 16, 2011 at 4:18 AM, Ron Wilson ronw.m...@gmail.com wrote: On Wed, Sep 14, 2011 at 6:40 PM, Stephan Beal Instead of sending the password in plain text, you hash the password with a nonce received from the server. Of course, to get the nonce, you have to attempt to login without supplying credentials. The server would then respond with a payload containing the nonce to use in the hash. The problem with that is that we need the hash routine for every client language :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON login demo: is this interface acceptable?
On 9/15/2011 10:18 PM, Ron Wilson wrote: For the password on GET, you could mimic what HTTP-Auth-Digest does. AFAIK, in every programming context where you'd want to make a JSON request, POST is as easy to do as GET. The main reason to support GET at all is to make it easy for people to experiment with the API manually, which would be completely defeated by requiring a two-request login process and hashing. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] JSON login demo: is this interface acceptable?
Hi, all!
Just implemented...
Request:
GET: /json/login?n=namep=pass
Param names n and p are for compatibility with the current usage, and
may optionally be written out as name and password.
or POST: /json/login
POST request body: { payload:{name:..., password:...} }
(POSTed login data doesn't land in the apache logs, so it's highly
preferred!)
Response:
{
fossil:ff6485c5c8a81716dc9d8a70e4eff3db623f5d54,
timestamp:1316035948,
payload:BCB43F00AF73F290571512747DDFC8B3358C47836B4CFA56D9/CE59BB9F186226D8/stephan
}
The response payload is the value of the fossil cookie, which also gets set:
Set-Cookie:fossil-CE59BB9F186226D8=BCB43F00AF73F290571512747DDFC8B3358C47836B4CFA56D9%2FCE59BB9F186226D8%2Fstephan;
Path=/cgi-bin/fossil.cgi; expires=Fri, 14 Sep 2012 04:32:28 GMT; HttpOnly;
Version=1
i might change the payload to also include the cookie name (fossil-CE5... in
the example above), but i don't yet know if i need it at this level.
i haven't yet done anonymous user support (that requires special handling
because of the random password). Nor have i yet thoroughly tested THIS
support (it's literally under 10 minutes old). Seems to work.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
