On 5/18/2015 12:23 PM, Richard Hipp wrote:
On 5/18/15, Ross Berteig <r...@cheshireeng.com> wrote:
On 5/15/2015 7:03 PM, Richard Hipp wrote:
Imagine a user Hortense who in the course of history, had access to A
and B, but before I realized that there should be a login group at all.
So she has accounts in both repos, and likely has different passwords in
those accounts.
I go and create the login group, with B logging in to A.
From what I'm seeing, Hortense will be able to log in to A as she
always had, but will now have trouble with B.
it *should* work. Maybe there is a bug.
One work-around might be to have Hortense login on A then change her
password there. That should also reset the password on B.
That workaround seem to work, but there does seem to be a bug lurking
around the special case of user accounts that existed before the
login-group was created.
To demonstrate this, I created A.fossil, B.fossil, and C.fossil, in a
folder that is already shared by inetd.conf, which launches "fossil
http" on a specific port for the entire folder as root. A and B will
join a login group. C will be a control.
fossil init A.fossil
fossil init B.fossil
fossil init C.fossil
I created my historical user Hortense in all three
fossil user -R A.fossil new Hortense Hortense Hello
fossil user -R B.fossil new Hortense Hortense Hairy
fossil user -R C.fossil new Hortense Hortense Horse
Next, I joined them together in a login-group, which apparently cannot
be done from the command line. (I can't imagine a good use for that in a
script other than a test case, but this test would be more convenient to
document if more of it could be done from a shell script.)
I used my normal browser from another PC, logging in to B.fossil with
the admin-user reported by fossil init. The fossil ui command would work
here too, except that it is hard to get the file name of the repository
right from fossil ui when it is normally accessed inside a chroot jail.
The server provided by fossil ui is not chroot, and it tries to write
down the cannonical file name for the other repository, and that name is
not accessible from the jail.
With the login-group in place, I logged out of the admin-user, then
attempted to log in as Hortense.
On C.fossil, the control, she logs in just fine.
On B.fossil, neither her old password to B.fossil nor the password to
A.fossil work.
On A.fossil, her password works. Once logged in to A.fossil, she has
access to B because the session cookie cookie is working as a single
sign on. Logging out from either B or A logs her out of both. She can
only log in at A's login screen, not B's.
I created a new users in both repositories. I gave David a password in
A, but not in B.
fossil user -R A.fossil new David David david
fossil user -R B.fossil new David David
On C.fossil, David is unable to log in as expected. It is neither part
of the group, and he has no account.
On B.fossil, David logged in with the password set for A.fossil. He is
now logged in to both A and B, and both logout buttons work equally well.
On A.fossil, David logged in with the password set for A.fossil. He is
now logged in to both A and B, and both logout buttons work equally well.
I then logged Hortense into A.fossil, changed her password to "Who", and
logged her out.
On B.fossil, Hortense logged in with her new password to A.fossil. She
is now logged in to both A and B, and both logout buttons work equally well.
On A.fossil, Hortense logged in with her new password to A.fossil. She
is now logged in to both A and B, and both logout buttons work equally well.
For my immediate need, I think I'll be fine with just adding users to
both, having joined to the one with all the users. I will deal with the
three users that were already in both before the join specially. Since
those are all internal users, that isn't a big deal.
So the bottom line is that there is a bug, but it has a clear
work-around, and isn't likely to be a showstopper. So unless someone who
already knows how fossil's user authentication works internally is
already jumping up and down with an idea of how to fix it, don't block
your release of 1.34 for this.
--
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
