[fossil-users] JSON API and WSDL

[Stephan Beal]

Hi, all,

"It would be cool if" the JSON API had a way to serve a WSDL of its API. i'm
looking to pick someone's brain about WSDL, namely regarding:

a) Is WSDL intended only for SOAP (in which case it is not interesting
here)?
b) Does anyone know of a JSON-format WSDL-like language?

What i'd like to eventually have is:

http://my.fossil-server.org/json/

which would fetch the WSDL[-like] description of the API, which the client
could then use to automatically generate an object-oriented implementation
class. e.g. PHP can use a WSDL to generate (at runtime) classes which
reflect arbitrary SOAP interfaces.

:-?

-- 
- 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 API and WSDL

[Martin S. Weber]

On 09/14/11 11:21, Stephan Beal wrote:

Hi, all,

"It would be cool if" the JSON API had a way to serve a WSDL of its API.
i'm looking to pick someone's brain about WSDL, namely regarding:

a) Is WSDL intended only for SOAP (in which case it is not interesting
here)?


See section 4 [1] of the WSDL spec [2]. Short: there do exist http get/post 
bindings for WSDL; there is support for mimetypes, and thus application/json 
application/x-javascript text/javascript text/x-javascript (take your pick or 
use something completely different ;))


[1] http://www.w3.org/TR/wsdl#_http
[2] http://www.w3.org/TR/wsdl

-Martin
___
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 API and WSDL

[Stephan Beal]

On Wed, Sep 14, 2011 at 5:31 PM, Martin S. Weber wrote:

> bindings for WSDL; there is support for mimetypes, and thus
> application/json application/x-javascript text/javascript text/x-javascript
> (take your pick or use
>
something completely different ;))
>

i think you just found a bug in my code - i've been using
"application/javascript" instead of "application/x-javascript". What's even
worse, the amount of documentation which now needs to be changed is far
larger than the code ;).

For the fossil/json response headers we actually try to determine which
Content-Type to send based on the Accept header of the client, using one of
application/json, application/javascript, or falling back to text/plain if
we can't figure out what to do.


> [1] http://www.w3.org/TR/wsdl#_**http 
> [2] http://www.w3.org/TR/wsdl


Thank you very much :). i'll go get myself more informed on the topic...

-- 
- 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

[fossil-users] Fossil tutorial - Oct 25 in Manassas VA

[Richard Hipp]

I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct
25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk
conference.  See http://www.tcl.tk/community/tcl2011/schedule.html for
schedule and registration information.  In addition to usual high-level
information about the history and usage of DVCSes in general and Fossil in
particular, I plan to go into detail about the internal data structures,
code organization, and file format for Fossil, with the idea of equipping
users with behind-the-scenes information that will help them to make more
effective use of Fossil, and to better understand why Fossil behaves the way
it does.

-- 
D. Richard Hipp
d...@sqlite.org
___
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 API and WSDL

[Stephan Beal]

On Wed, Sep 14, 2011 at 5:40 PM, Stephan Beal  wrote:

> On Wed, Sep 14, 2011 at 5:31 PM, Martin S. Weber wrote:
>
>> [1] http://www.w3.org/TR/wsdl#_**http 
>> [2] http://www.w3.org/TR/wsdl
>
>
> Thank you very much :). i'll go get myself more informed on the topic...
>

If i'm understanding correctly, WSDL requires that parameters passed to the
server be form-urlencoded. That's not fundamentally a problem, but there is
a current "conflict of interest" regarding who (fossil's core or the JSON
bits) gets to parse the POST data (which we can only do once unless we
buffer it into a Blob first). The current heuristics are:

a) If the Content-Type of the request is application/json or text/plain then
the json/cgi bits try to parse it as JSON. This makes it unavailable to
fossil, as the json/cgi init bits must be run before fossil initializes its
side of the CGI environment (because parts of the fossil internals - namely
error reporting - now account for "JSON mode" and output a JSON error
object).

b) if the Content-Type is form-urlencoded or one of the fossil-specific
types then fossil gets to process it.

c) If we don't know the Content-Type then we ignore (neither consume nor
parse) the POST data.

This works so far, but will fail once we allow the JSON API to read
form-urlencoded data (which it has code to do but it currently does do so
not because that would interfere with (=completely break) ALL of
fossil's POSTed form handling).

In order to resolve this "conflict of interests" i need to add some code to
the json/cgi bits (an external/independent library) to allow delayed reading
of the POST data (it is currently done automatically at lib-init time, which
ends up preempting fossil), so that the fossil code can properly decide who
to feed the POST data to.

Anyway... that's certainly more than anyone really wanted to know.

-- 
- 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] Fossil tutorial - Oct 25 in Manassas VA

[Stephan Beal]

On Wed, Sep 14, 2011 at 5:42 PM, Richard Hipp  wrote:

> I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct
> 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk
> conference.


Will there be a video of it online afterwards? :)

-- 
- 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] Fossil tutorial - Oct 25 in Manassas VA

[Wes Freeman]

Any discount codes for fossil user group members? Manassas is
convenient for me, so I would consider going just for your talk.

Thanks,
Wes
___
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 API and WSDL

[Stephan Beal]

On Wed, Sep 14, 2011 at 5:31 PM, Martin S. Weber wrote:

> [1] http://www.w3.org/TR/wsdl#_**http 
> [2] http://www.w3.org/TR/wsdl
>
>
To follow up:

http://tools.ietf.org/html/draft-zyp-json-schema-03

looks interesting (but i need to finish reading it).

And WSDL 2.0 apparently accounts for non-XML representations:

http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/

They mention JSON as an alternative, but it's not yet clear to me whether
there actually is an example of a JSON variant out there and whether or not
it could be used for this purpose.

-- 
- 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] Fossil tutorial - Oct 25 in Manassas VA

[Richard Hipp]

On Wed, Sep 14, 2011 at 11:57 AM, Stephan Beal wrote:

> On Wed, Sep 14, 2011 at 5:42 PM, Richard Hipp  wrote:
>
>> I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday,
>> Oct 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk
>> conference.
>
>
> Will there be a video of it online afterwards? :)
>

I checked with the conference organizers and they tell me "no".  The
tutorials are how they defray the fixed costs of putting on the conference
in the first place.  And that makes sense.

I also asked about Wes's question of a discount.  They pointed out to me
that you can register for just this one tutorial and not the technical
sessions.  But, again, the tutorial fees are how they pay for the room, so
no discounts.


>
> --
> - 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
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
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 authentication: meshing with the cookie mechanism

[Stephan Beal]

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 commit message contents) and i need to account for that early on.

What i need to be able to do is (in no particular order):

a) If a login request comes from JSON, ignore the authentication cookie (if
any) and funnel the login data sent in the JSON request through to the
current login mechanism. When it's done, i need to pass the generated cookie
(i call it "the auth token") back to the requester (in the JSON response
payload) so that he can include it in future requests which require
non-guest access. It is up to the client to remember his auth token and
include it with each request (this is easy to encapsulate in client-side
APIs).

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 cookie from the HTTP header, though i'm really feeding it the cookie
from JSON.

d) If no auth token is set in the request, check for it in the HTTP cookies
(i.e. do what fossil does currently).

e) the various auth functions like login_check_credentials() need to work as
before (with the exception that they will produce JSON output on errors).
Though i might need to touch their internals in order to connect the
JSON/cookie world views, i would prefer to be able to hook in to it at a
deeper level (i.e. when the cookie is initially processed and where it is
ultimately evaluated).

Can someone suggest where i should hook into fossil's cookie mechanism? The
main goal here is to touch as little existing code as possible.

PS: i have NO idea if what i'm doing here will work as proposed with
fossil's "group login" functionality, and i haven't ever personally used
those features so i don't know off hand what would be required to support
them.

-- 
- 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] Fossil tutorial - Oct 25 in Manassas VA

[Stephan Beal]

On Wed, Sep 14, 2011 at 6:19 PM, Richard Hipp  wrote:

> I checked with the conference organizers and they tell me "no".  The
> tutorials are how they defray the fixed costs of putting on the conference
> in the first place.  And that makes sense.
>

Fair enough. Could we convince you to "accidentally" leave your webcam
turned on during the presentation (and conveniently point it as the screen)?
;)

-- 
- 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] Fossil tutorial - Oct 25 in Manassas VA

[Stephan Beal]

On Wed, Sep 14, 2011 at 6:28 PM, Stephan Beal  wrote:

> Fair enough. Could we convince you to "accidentally" leave your webcam
> turned on during the presentation (and conveniently point it as the screen)?
> ;)
>

Or do they have an option to buy a copy online? That'd be win-win for them,
i'd think.

-- 
- 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] Fossil tutorial - Oct 25 in Manassas VA

[Remigiusz Modrzejewski]

On Sep 14, 2011, at 6:28 PM, Stephan Beal wrote:

> Fair enough. Could we convince you to "accidentally" leave your webcam
> turned on during the presentation (and conveniently point it as the screen)?
> ;)

Isn't it easier and more responsible to just record a rehearsal?


Kind regards,
Remigiusz Modrzejewski



___
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] Fossil tutorial - Oct 25 in Manassas VA

[Wes Freeman]

On Wed, Sep 14, 2011 at 12:19 PM, Richard Hipp  wrote:
>
> I also asked about Wes's question of a discount.  They pointed out to me
> that you can register for just this one tutorial and not the technical
> sessions.  But, again, the tutorial fees are how they pay for the room, so
> no discounts.
>

Thanks for checking. Looks like $195 for the tutorial, to save others
the effort of looking it up. I might try to get my employer to pay for
it, which would increase my chances of attending by 95%. Thanks for
letting us know about it, in any case.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] proposed cleanup to g.okXXX code?

[Stephan Beal]

Hi, all,

i'm wondering if anyone would be against me making the following change to
the 'g' object:

Extend its structure to include:

struct FossilPermissions {
  char setup;
  char admin;
  ... repeat for all current g.okXXX bits ...
} perm;

Remove all of the g.okXXX members, replacing their uses with g.perm.XXX.

One advantage (though very minor) would be future-proofing code
like login_as_user() against the addition of future permissions (which must
currently be explicitly set there, whereas the above replaces all that with
a simple memset()).

???

-- 
- 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] proposed cleanup to g.okXXX code?

[Richard Hipp]

On Wed, Sep 14, 2011 at 12:52 PM, Stephan Beal wrote:

> Hi, all,
>
> i'm wondering if anyone would be against me making the following change to
> the 'g' object:
>
> Extend its structure to include:
>
> struct FossilPermissions {
>   char setup;
>   char admin;
>   ... repeat for all current g.okXXX bits ...
> } perm;
>

I think this is a great idea.


>
> Remove all of the g.okXXX members, replacing their uses with g.perm.XXX.
>
> One advantage (though very minor) would be future-proofing code
> like login_as_user() against the addition of future permissions (which must
> currently be explicitly set there, whereas the above replaces all that with
> a simple memset()).
>
> ???
>
> --
> - 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
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
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 authentication: meshing with the cookie mechanism

[Ron Wilson]

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 cookie from the HTTP header, though i'm really feeding it the cookie
> from JSON.
> d) If no auth token is set in the request, check for it in the HTTP cookies
> (i.e. do what fossil does currently).

Are you proposing supporting non-HTTP transport of JSON client-server
interaction?

If not, why would the auth token be put in the JSON payloead rather
than in the HTTP headers?
___
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] proposed cleanup to g.okXXX code?

[Stephan Beal]

On Wed, Sep 14, 2011 at 6:57 PM, Richard Hipp  wrote:

> On Wed, Sep 14, 2011 at 12:52 PM, Stephan Beal wrote:
>
>> ...struct FossilPermissions {
>>   char setup;
>>   char admin;
>>   ... repeat for all current g.okXXX bits ...
>> } perm;
>>
>
> I think this is a great idea.
>

i've got this ready to commit. Would you prefer a branch for review or
directly to the trunk?  The impl was a global search/replace with one
exception made for g.okCsrf (which i left where it is because i have no clue
what it is). "Seems to work," e.g. anonymous user can't edit a checkin but
my account can.

-- 
- 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 authentication: meshing with the cookie mechanism

[Stephan Beal]

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 client code doesn't support cookies, so it has to pass around its
authentication in the JSON request. Cookies are, for purposes of the JSON
API, the fallback and not the default.

-- 
- 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 authentication: meshing with the cookie mechanism

[Stephan Beal]

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
> authentication in the JSON request. Cookies are, for purposes of the JSON
> API, the fallback and not the default.
>

BTW: many SOAP interfaces do this as well. When logging in you get a token
(which fossil stores as a cookie), and that token has to be included in
requests which require non-guest access.

-- 
- 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 authentication: meshing with the cookie mechanism

[Richard Hipp]

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 some requests (e.g. whether or not links are generated
> from commit message contents) and i need to account for that early on.
>
> What i need to be able to do is (in no particular order):
>
> a) If a login request comes from JSON, ignore the authentication cookie (if
> any) and funnel the login data sent in the JSON request through to the
> current login mechanism. When it's done, i need to pass the generated cookie
> (i call it "the auth token") back to the requester (in the JSON response
> payload) so that he can include it in future requests which require
> non-guest access. It is up to the client to remember his auth token and
> include it with each request (this is easy to encapsulate in client-side
> APIs).
>

Three are multiple authentication modes.

When running as CGI, if the REMOTE_USER environment variable is set, then
the interaction is deemed to be from the named user.  The idea is that the
web server should have handled the authentication for us and set the
REMOTE_USER environment variable correctly, and Fossil trusts the web
server.

Otherwise, most requests look for a cookie of the form
"fossil-X" where XXX is replaced by either the group-code or the
project-code.  The value of the cookie needs to be of a particular form
which is different depending on whether the login is as "anonymous" or as a
normal named user.  For anonymous users, the cookie contains (among other
things) a hash of the remote IP address as a defense against cookie
stealing.  For named users, the IP address and a random code is stored in
the USER table and the random code is contained in the cookie.  Hence, the
same user cannot be logged in from two or more machines at the same time.

The push/pull/sync protocol has its own separate authentication mechanism.

I'm thinking you don't need to change or enhance any of this for JSON.
Rather, just have the JSON client receive and interpret SET-COOKIE headers
in the HTTP reply, and reply with corresponding COOKIE headers in subsequent
requests.  You might want the equivalent of a /login screen that returns
JSON rather than HTML, but other than that, I don't think you need to add
anything on the server side.


>
> 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 cookie from the HTTP header, though i'm really feeding it the cookie
> from JSON.
>
> d) If no auth token is set in the request, check for it in the HTTP cookies
> (i.e. do what fossil does currently).
>
> e) the various auth functions like login_check_credentials() need to work
> as before (with the exception that they will produce JSON output on errors).
> Though i might need to touch their internals in order to connect the
> JSON/cookie world views, i would prefer to be able to hook in to it at a
> deeper level (i.e. when the cookie is initially processed and where it is
> ultimately evaluated).
>
> Can someone suggest where i should hook into fossil's cookie mechanism? The
> main goal here is to touch as little existing code as possible.
>
> PS: i have NO idea if what i'm doing here will work as proposed with
> fossil's "group login" functionality, and i haven't ever personally used
> those features so i don't know off hand what would be required to support
> them.
>
> --
> - 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
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
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] proposed cleanup to g.okXXX code?

[Richard Hipp]

On Wed, Sep 14, 2011 at 1:22 PM, Stephan Beal  wrote:

> On Wed, Sep 14, 2011 at 6:57 PM, Richard Hipp  wrote:
>
>> On Wed, Sep 14, 2011 at 12:52 PM, Stephan Beal wrote:
>>
>>> ...struct FossilPermissions {
>>>   char setup;
>>>   char admin;
>>>   ... repeat for all current g.okXXX bits ...
>>> } perm;
>>>
>>
>> I think this is a great idea.
>>
>
> i've got this ready to commit. Would you prefer a branch for review or
> directly to the trunk?  The impl was a global search/replace with one
> exception made for g.okCsrf (which i left where it is because i have no clue
> what it is). "Seems to work," e.g. anonymous user can't edit a checkin but
> my account can.
>

Branch, please


>
> --
> - 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
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
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 authentication: meshing with the cookie mechanism

[Stephan Beal]

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 tell fossil to use my own string as the auth cookie, as
opposed to (or overriding) the HTTP cookie.

Is there already an internal function to which i could pass, e.g.
"fossil-ABCDEF=xx", and have it interpret that as the cookie? i think
that's basically the functionality i need.

-- 
- 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] proposed cleanup to g.okXXX code?

[Stephan Beal]

On Wed, Sep 14, 2011 at 7:36 PM, Richard Hipp  wrote:

> Branch, please
>

http://fossil-scm.org/index.html/timeline?r=stephan-hack

It touches a lot of files but the changes are minimal.

Note that g.okRead translates to g.perm.Read as opposed to g.perm.read
because... it was easiest to automate that way. If you'd prefer lower-cased
first letters i can do that.

-- 
- 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 authentication: meshing with the cookie mechanism

[Richard Hipp]

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 expecting, but i think the one place i need to change
> would be a way to tell fossil to use my own string as the auth cookie, as
> opposed to (or overriding) the HTTP cookie.
>
> Is there already an internal function to which i could pass, e.g.
> "fossil-ABCDEF=xx", and have it interpret that as the cookie? i think
> that's basically the functionality i need.
>

cgi_set_parameter("fossil-ABCDEF", "xx");


>
> --
> - 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
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
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 authentication: meshing with the cookie mechanism

[Stephan Beal]

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 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 authentication: meshing with the cookie mechanism

[Richard Hipp]

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 fossil has done its
> cookie cutting).
>

To clarify, Fossil uses a single namespace to hold all environment
variables, cookies, query parameters, and POST parameters.  All of things
are name/value pairs, and they all go into a common look-up table.  So there
is no way in Fossil to ask for the value of a cookie, for example.  You have
to ask for the value associated with a name, where that name/value might be
any of a an environment variable, cookie, query parameter or POST
parameter.  They all work the same.

Note however, that query parameters, POST parameters, and cookies always use
lower-case names and environment variables use upper-case names.  So there
is no way to generate a rogue request that overrides an environment variable
using a query parameter, for example.  In other words, you cannot do:

 http://www.fossil-scm.org/fossil/xfer?REMOTE_USER=drh

... hoping to subvert the login mechanism and push content under my name.
But you can interchange cookies, query parameters, and POST parameters, and
Fossil won't notice.



>
> Thanks!
>
> --
> - 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
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
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 authentication: meshing with the cookie mechanism

[Stephan Beal]

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 where this
belongs. login_check_credentials() is rather complex due to the handling of
various login sources and the anonymous user (i foresee a problem on my side
in handling the captcha seed - i will probably need an extra request which
fetches this seed).


> Note however, that query parameters, POST parameters, and cookies always
> use lower-case names and environment variables use upper-case names.  So
>

That's good to know.


> there is no way to generate a rogue request that overrides an environment
> variable using a query parameter, for example.  In other words, you cannot
> do:
>
>  http://www.fossil-scm.org/fossil/xfer?REMOTE_USER=drh
>
> ... hoping to subvert the login mechanism and push content under my name.
>

Oh, you know i wouldn't think of trying that! ;)


> But you can interchange cookies, query parameters, and POST parameters, and
> Fossil won't notice.
>

Great - that's part of what i need to do, e.g. to allow certain request
options to either be set via GET params or POST request properties.

Anyway... i think i've been pointed in the right direction, now i just need
to go get it working.

Thanks again for the help,

-- 
- 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] fossil update FAIL

[sky5walk]

Ok,
Didn't realize there was a disconnected Leaf in the remote repo.
  c:\myrepo> fossil merge 88d803c051
worked.

We still are unsure what created the disconnect?
Though we seem to have hiccups when upgrading the fossil.exe and doing
rebuilds on both local and remote repos.

On Tue, Aug 30, 2011 at 7:10 PM,   wrote:
> Hi,
> I ran into a snag today after a week away on vacation.
> This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC
>
> I performed a pull.
> c:\myrepo> fossil pull t:\myrepo\myrepo1.fossil
> ...lots of changes came down the network...
>                Bytes      Cards  Artifacts     Deltas
> Sent:             130          1          0          0
> Received:        2056         45          0          0
> Sent:            1023         20          0          0
> Received:       11346         64          0         19
> Total network traffic: 957 bytes sent, 6805 bytes received
>
> I then ran an update.
> c:\myrepo> fossil update
> ...nothing happened. no report?
> ...But I assumed my checkout contained the latest changes.
> ...So I began to edit my code and noticed none of the changes were there.
>
> Question: What should I do in this case?
>
> I eventually got things aligned with 2 cycles of close/open.
> Not sure why?
> I ran a close.
> c:\myrepo> fossil close
>
> I ran an open.
> c:\myrepo> fossil open myrepo.fossil
> ...Still no update of my folder contents!
> Repeat worked.
>
> Maybe if I automated this via a script, I would have stopped
> immediately after receiving no report on the update?
>
> Thanks for your help.
>
___
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 authentication: meshing with the cookie mechanism

[Ben Summers]

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 cookies, so it has to pass around its 
>> authentication in the JSON request. Cookies are, for purposes of the JSON 
>> API, the fallback and not the default.
>> 
> BTW: many SOAP interfaces do this as well. When logging in you get a token 
> (which fossil stores as a cookie), and that token has to be included in 
> requests which require non-guest access.

HTTP basic authentication is widely supported in HTTP client libraries, and 
much less hassle to use than passing tokens around.

Ben


--
http://bens.me.uk/



___
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 authentication: meshing with the cookie mechanism

[Joshua Paine]

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) Requires sending the username and password over the wire

1 and 2 are irrelevant for a JSON API, and fossil's web ui already sends 
the username and password in the clear over the wire unless you're using 
HTTPS, so this is no greater risk, and it inherits the protection that 
an HTTPS setup provides.


I vote for HTTP Basic Auth, provided that someone can confirm the major 
browser AJAX functions support it.


(Curl and other libs certainly support it.)

--
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

Re: [fossil-users] JSON authentication: meshing with the cookie mechanism

[Stephan Beal]

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 manage the login/auth
data. i _think_ i have it set up more or less correctly now (as of about 3
minutes ago), but i still need to write a another function or two before i
can actually test a login made over json. The good news is that a
/json/login request at least does _something_:

{
"fossil": "74273decba0a4db0b86d4769d4f5f2c923c35773",
"timestamp": 1316028489,
"resultCode": "FOSSIL-1008",
"resultText": "Not yet implemented."
}

;)

-- 
- 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 authentication: meshing with the cookie mechanism

[Richard Hipp]

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) No pretty login page
> 2) No reliable way to logout in most browsers
> 3) Requires sending the username and password over the wire
>
> 1 and 2 are irrelevant for a JSON API, and fossil's web ui already sends
> the username and password in the clear over the wire unless you're using
> HTTPS, so this is no greater risk, and it inherits the protection that an
> HTTPS setup provides.
>
> I vote for HTTP Basic Auth, provided that someone can confirm the major
> browser AJAX functions support it.
>

Note that Basic Auth is normally handled by the web server, not the client
application.  The web server checks the credentials and then sets the
REMOTE_USER environment variable.  Fossil honors the REMOTE_USER environment
variable in CGI mode, so you can use Fossil with Basic Auth.  But, it comes
with all the downsides listed above, plus it means that the Admin/User page
will no longer work for setting and changing passwords since the passwords
are now stored in the web server, not in Fossil.

One other thing:  I don't think Basic Auth allows anything equivalent to the
current "nobody" user or the "anonymous" user.  If you don't have a valid
login and password you cannot see anything at all.  That would be downside
#5, if I'm counting right


>
> (Curl and other libs certainly support it.)
>
> --
> 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
>



-- 
D. Richard Hipp
d...@sqlite.org
___
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 authentication: meshing with the cookie mechanism

[Ben Summers]

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.
>>> 
>> The three major downsides with HTTP Basic Auth are:
>> 
>> 1) No pretty login page
>> 2) No reliable way to logout in most browsers
>> 3) Requires sending the username and password over the wire
>> 
>> 1 and 2 are irrelevant for a JSON API, and fossil's web ui already sends the 
>> username and password in the clear over the wire unless you're using HTTPS, 
>> so this is no greater risk, and it inherits the protection that an HTTPS 
>> setup provides.
>> 
>> I vote for HTTP Basic Auth, provided that someone can confirm the major 
>> browser AJAX functions support it.
>> 
> Note that Basic Auth is normally handled by the web server, not the client 
> application.  The web server checks the credentials and then sets the 
> REMOTE_USER environment variable.  Fossil honors the REMOTE_USER environment 
> variable in CGI mode, so you can use Fossil with Basic Auth.  But, it comes 
> with all the downsides listed above, plus it means that the Admin/User page 
> will no longer work for setting and changing passwords since the passwords 
> are now stored in the web server, not in Fossil.

I believe that if you don't ask the web server to handle it, it'll just pass on 
the raw headers to the CGI script. Apache certainly works that way with 
proxying.

> 
> One other thing:  I don't think Basic Auth allows anything equivalent to the 
> current "nobody" user or the "anonymous" user.  If you don't have a valid 
> login and password you cannot see anything at all.  That would be downside 
> #5, if I'm counting right

It's probably best implemented without enforcing the use of basic auth. So if 
the headers aren't present, don't return a 401, just do everything as now. You 
then get the best of both worlds, tokens or cookies and the option to use basic 
auth when it's the easiest mechanism available.

Ben


--
http://bens.me.uk/



___
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 authentication: meshing with the cookie mechanism

[Joshua Paine]

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 of a JSON API.

Seems like this unfortunately means that the JSON API can't be designed 
so that a single auth method works for most fossil installs.


Though if the JSON parts also trust the REMOTE_USER (when it's set), 
then one could pretty easily have the client follow whatever login 
procedure and *also* send the HTTP AUTH info with all requests, and that 
should at least make it possible to write a fossil JSON client without 
knowing which way a given repo swings.


--
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

Re: [fossil-users] JSON authentication: meshing with the cookie mechanism

[Stephan Beal]

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 means that the JSON API can't be designed so
> that a single auth method works for most fossil installs.
>

i'm piggybacking on fossil's method insofar as possible, and the goal is for
them to transparently work together. i won't be (intentionally) breaking any
of fossil's current login-related conventions, in any case.


> Though if the JSON parts also trust the REMOTE_USER (when it's set), then
> one could pretty easily have the client follow whatever login procedure and
> *also* send the HTTP AUTH info with all requests, and that should at least
> make it possible to write a fossil JSON client without knowing which way a
> given repo swings.
>

That's the goal, but i'm still a ways away from adding the REMOTE_USER
handling. That said... if i'm understanding the code correctly, i won't have
to do anything for that - it should "just work" after i call
login_check_credentials() (which happens as part of the JSON init phase when
running in CGI mode).

Interestingly, if i try to handle auth in CLI mode i run into a chicken/egg
scenario where i need to call login_cookie_name() but the repo hasn't been
opened yet (so login_cookie_name() can't work). However - auth is not used
in CLI mode, so i've got no problem there (i just skip JSON auth setup if
we're not in CGI mode).

-- 
- 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 authentication: meshing with the cookie mechanism

[Stephan Beal]

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 incrementally convert features from "static mode" to client-side
JavaScript.

Assuming that would even be desired. (But i'm getting ahead of myself... we
need to crawl before we can walk, and all that.)

-- 
- 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

[fossil-users] JSON login demo: is this interface acceptable?

[Stephan Beal]

Hi, all!

Just implemented...

Request:

GET: /json/login?n=name&p=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

[fossil-users] RFC: new config option name

[Stephan Beal]

Hiya!

The JSON API returns errors in the form of 4-digit error codes, as described
here:

https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?hl=en_US

The codes are grouped such that we can "dumb down" error codes to be less
specific (w/ 3 levels of specificity), for the sake of not revealing
potentially security-relevant codes to clients. The dumbing-down support is
implemented but currently uses a hard-coded dumb-down level (called
g.json.errorDetailParanoia) which i would like to switch to a configuration
option.

But what to call it?

json-paranoia-level?
json-error-dumbdown-level?
something complete different?

-- 
- 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

[fossil-users] same user, multiple logins: the problem and a potential solution

[Stephan Beal]

Hi again,

As Richard mentioned earlier, the current fossil login mechanism does not
tolerate a given user being logged in multiple times (each new login
invalidates the previous one). While this almost certainly isn't a real
limitation for the HTML interface, it will eventually become one for the
JSON interface. e.g. i might have one applet for polling a timeline and
another for polling tickets. That wouldn't work right now unless i force a
re-login from each client (and can avoid the inevitable login/poll race
condition between the two apps).

In a recent project of mine i have the same limitation of one login per user
(because i don't want the db filling up with stale login state data) but i
allow multiple logins for one user by recycling the login auth
token values (analog to fossil's cookie value) if a user performs a login
while a login is already active. The login op then always returns the same
auth token for the given user/password until an explicit logout is performed
(which clears the user.cookie value) or fossil cleans up the cookie because
it expired (i don't know if it currently does any cookie cleaning but it
does store the expiry time in user.cexpire).

Would this modification be acceptable in fossil? i know it's a bit
unconventional, but should be a fairly simple change to make with no
backwards compatibility concerns (because fossil doesn't support multiple
logins for one user right now).

:-?

-- 
- 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] same user, multiple logins: the problem and a potential solution

[Ross Berteig]

At 04:17 PM 9/14/2011, Stephan Beal wrote:
>Would this modification be acceptable in fossil? i know it's a
>bit unconventional, but should be a fairly simple change to make
>with no backwards compatibility concerns (because fossil doesn't
>support multiple logins for one user right now).

Chiming in from an end user perspective, I personally find it
annoying that fossil does not allow multiple logins for a single
user. I work from both home and office, and having a logged in
session at the office go poof just because I wanted to update a
ticket from home is a minor annoyance that I accept, but would
love to see eliminated. I've toyed with the obvious work-around
of creating a second user to log in from home, but that just
feels wrong.

None of the major user web applications I use regularly (GMail
and the Google family, FB, StackOverflow, Flickr) log me out from
one computer just because I touched them from my Android phone or
from another computer.

Again, I'm writing this as a user, paying no attention to how
difficult this would be to address under the hood.


Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
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] same user, multiple logins: the problem and a potential solution

[Stephan Beal]

On Thu, Sep 15, 2011 at 1:30 AM, Ross Berteig  wrote:

> At 04:17 PM 9/14/2011, Stephan Beal wrote:
> >Would this modification be acceptable in fossil? i know it's a
> >bit unconventional, but should be a fairly simple change to make
> >with no backwards compatibility concerns (because fossil doesn't
> >support multiple logins for one user right now).
>

i just this moment realized this change can't work as-is with fossil because
fossil uses the first part of the IP address in calculating the auth token
(and stores that IP prefix in the db). So my proposal would break the moment
you have a login from your mobile phone and your PC simultaneously.


> Chiming in from an end user perspective, I personally find it
> annoying that fossil does not allow multiple logins for a single
> ...love to see eliminated. I've toyed with the obvious work-around
> of creating a second user to log in from home, but that just
> feels wrong.
>

i agree.


> None of the major user web applications I use regularly (GMail
> and the Google family, FB, StackOverflow, Flickr) log me out from
> one computer just because I touched them from my Android phone or
> from another computer.
>

i believe (theorize) the reason for this limitation is to avoid cluttering
the db with an arbitrary number of stale login sessions. At least that's the
reason i implemented that way in my own app. But my app's approach doesn't
use the IP checking which fossil does, so i didn't have the problem
described above.


> Again, I'm writing this as a user, paying no attention to how
> difficult this would be to address under the hood.
>

i think if we got rid of (gasp!) the IP check we could easily implement
this, but i can't just take that part out without a blessing from the higher
powers.

-- 
- 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] same user, multiple logins: the problem and a potential solution

[Ross Berteig]

At 04:33 PM 9/14/2011, Stephan Beal wrote:
>
>i think if we got rid of (gasp!) the IP check we could easily
>implement this, but i can't just take that part out without a
>blessing from the higher powers.

I found a thread that I started back in March of 2010 about this
from a user experience point of view. The thread stalled out
after a patch was offered by Kyle McKay[1] that would have
dropped the use of the IP adderss in the session cookie hash,
allowing the same session cookie to be used from any IP address
until the session was explicitly logged out.

[1]: 
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01621.html


It appears that DRH was ahead of the curve in making sessions
unique to a specific IP, the issue with all the major sites that
is exploited by session sniffing apps such as the infamous
firesheep plugin.

I should be possible to support more than one session cookie per
user, but then you would need a process to occasionally purge
stale sessions from the server. You could do that check on any
session validation, if its been long enough since the last check.
Or at least check a few sessions on each validation if that is
expensive to do en masse.

Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
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] same user, multiple logins: the problem and a potential solution

[Stephan Beal]

On Thu, Sep 15, 2011 at 2:54 AM, Ross Berteig  wrote:

> ...

from a user experience point of view. The thread stalled out
> after a patch was offered by Kyle McKay[1] that would have
> dropped the use of the IP adderss in the session cookie hash,
> allowing the same session cookie to be used from any IP address
> until the session was explicitly logged out.
>

That would be my proposal as well. Under that model, to prevent _others_
from logging you out, the logout requires that you give it the auth token
you were given by login. Since the tokens would be recycled, if you lose
your cookie/hash you can re-fetch it by performing a login, which you can
then use to logout and invalidate the hash.

The overall model is described here:

http://whiki.wanderinghorse.net/?page=WhikiAuthentication

(mentally substitute "auth token" for "fossil cookie" and the idea is the
same)

It appears that DRH was ahead of the curve in making sessions
> unique to a specific IP, the issue with all the major sites that
> is exploited by session sniffing apps such as the infamous
> firesheep plugin.
>

Computer security is one area i know absolutely nothing about, so i'll defer
to anyone's judgement on such topics.



> I should be possible to support more than one session cookie per
> user, but then you would need a process to occasionally purge
> stale sessions from the server. You could do that check on any
> session validation, if its been long enough since the last check.
> Or at least check a few sessions on each validation if that is
> expensive to do en masse.


Given the scope of even the largest fossil repos (by far under 100 users?),
cleanup would be fast, and could probably be performed before every login
request... doh... one could argue that cleaning up the logins should require
admin access...

-- 
- 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] same user, multiple logins: the problem and a potential solution

[Weber, Martin S]

> Ross Berteig:
> I should be possible to support more than one session cookie per
> user, but then you would need a process to occasionally purge
> stale sessions from the server. You could do that check on any
> session validation, if its been long enough since the last check.
> Or at least check a few sessions on each validation if that is
> expensive to do en masse.

Yeah I was thinking the same thing. If you don't want it to become unbounded, 
add a configuration parameter to determine how many parallel sessions any given 
user can have with a sane default (possibly even 1, thus not changing the 
current
behavior). I doubt (without measurements, which, of course, always is dangerous)
that it would become expensive to do this (at least in comparison to all the 
other
operations fossil is doing on the DB!), and I also, speaking as a user now, 
would
enjoy having multiple log-ins available.

That being said, I think the part where the IP is being woven into the hash
should stay.

Regards,
-Martin
___
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] same user, multiple logins: the problem and a potential solution

[Altu Faltu]

With the method suggested at below link, I see a problem that if I logout from 
one machine my auth token for other machine will also be invalidated.

 It would be simple to have one auth token for each login and purge stale auth 
tokens regularly. Purging stale tokens should be a matter of few SQLs for the 
current backend of fossil, sqlite.

 Then, we can enable multiple logins and also keep the current IP check as it 
is.

 - Altu

- Original Message -
From: Stephan Beal
Sent: 09/15/11 06:33 AM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] same user, multiple logins: the problem and a 
potential solution

 On Thu, Sep 15, 2011 at 2:54 AM, Ross Berteig < r...@cheshireeng.com > wrote:
 ...  from a user experience point of view. The thread stalled out
 after a patch was offered by Kyle McKay[1] that would have
 dropped the use of the IP adderss in the session cookie hash,
 allowing the same session cookie to be used from any IP address
 until the session was explicitly logged out.

 That would be my proposal as well. Under that model, to prevent _others_ from 
logging you out, the logout requires that you give it the auth token you were 
given by login. Since the tokens would be recycled, if you lose your 
cookie/hash you can re-fetch it by performing a login, which you can then use 
to logout and invalidate the hash.

 The overall model is described here:

http://whiki.wanderinghorse.net/?page=WhikiAuthentication 

 (mentally substitute "auth token" for "fossil cookie" and the idea is the same)
 It appears that DRH was ahead of the curve in making sessions
 unique to a specific IP, the issue with all the major sites that
 is exploited by session sniffing apps such as the infamous
 firesheep plugin.

 Computer security is one area i know absolutely nothing about, so i'll defer 
to anyone's judgement on such topics.

 I should be possible to support more than one session cookie per
 user, but then you would need a process to occasionally purge
 stale sessions from the server. You could do that check on any
 session validation, if its been long enough since the last check.
 Or at least check a few sessions on each validation if that is
 expensive to do en masse.

 Given the scope of even the largest fossil repos (by far under 100 users?), 
cleanup would be fast, and could probably be performed before every login 
request... doh... one could argue that cleaning up the logins should require 
admin access...
 --
 - 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] same user, multiple logins: the problem and a potential solution

[Ben Summers]

On 15 Sep 2011, at 00:17, Stephan Beal wrote:
> 
> As Richard mentioned earlier, the current fossil login mechanism does not 
> tolerate a given user being logged in multiple times (each new login 
> invalidates the previous one). While this almost certainly isn't a real 
> limitation for the HTML interface, it will eventually become one for the JSON 
> interface. e.g. i might have one applet for polling a timeline and another 
> for polling tickets. That wouldn't work right now unless i force a re-login 
> from each client (and can avoid the inevitable login/poll race condition 
> between the two apps).
> 
> In a recent project of mine i have the same limitation of one login per user 
> (because i don't want the db filling up with stale login state data) but i 
> allow multiple logins for one user by recycling the login auth token values 
> (analog to fossil's cookie value) if a user performs a login while a login is 
> already active. The login op then always returns the same auth token for the 
> given user/password until an explicit logout is performed (which clears the 
> user.cookie value) or fossil cleans up the cookie because it expired (i don't 
> know if it currently does any cookie cleaning but it does store the expiry 
> time in user.cexpire).


To solve this, you could use a different way of creating tokens with simple 
cryptographic signatures. You could concatenate the username and first 3 octets 
of the IP address, then sign it with a single secret key using an algorithm 
like HMAC-SHA1. [1]

For example, you could form the string

   stephan:192.168.0

then sign it with the secret key, and get

   stephan:192.168.0:38fa112673be4946702a74d1d0d1c0b6bd9f0162

To limit the validity of the tokens, include the time in the string being 
signed, and check it's in an acceptable range.

Advantages are that no state is stored in the database and multiple logins are 
possible, with simpler code.[2] You can invalidate all logins by changing the 
secret key, but can't invalidate individual sessions.

If you wanted to support logins from multiple locations in a browser which is 
run in multiple networks, include the partial IP address in the cookie name.

Ben


[1] https://secure.wikimedia.org/wikipedia/en/wiki/HMAC

[2] Although there are some subtle things you have to be careful of, mainly 
timing attacks. Safe approach: when checking the signature, don't use strcmp(), 
hash both strings then strcmp() the hashes.


--
http://bens.me.uk/



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users