On Mar 1, 2010, at 17:43:03 PST, Ross Berteig wrote:
Sometime on February 11, D. Richard Hipp wrote:
>Yes.  Fossil only allows a single login per user.  When a user
>logs in from a new web-browser, any prior login is cancelled.
>
>It never occurred to me that someone would want for the same user
>to be logged in simultaneously from multiple locations.  I suppose we
>could work on making that happen.

Here's a use case I ran into the other day. I am using a fossil
repository that contains only tickets. Since tickets don't
autosynch there doesn't seem to be much advantage to cloning it.
We host the repository on our internal web server, and access its
ticket system from there. Even for my other repositories where
there is content and ongoing checkin, push, and pull activity, it
is still often simpler to just fuss with tickets in the "master"
copy rather than in any of the clones on developer desks.

From home, I have a VPN tunnel into my office network that lets
me see that web server and log in to the repository. But that
login competes with the last login from the browser on my office
PC, unless I create a second account for me at home.

I would like to be logged in from home, laptop, and office to the
same user identity simultaneously. I haven't investigated how the
login cookie is actually implemented in fossil so I don't know
how hard it would be to relax this restriction.

A quick look at src/login.c suggests these changes:

Around line 225, look for these lines:

      const char *zIpAddr = PD("REMOTE_ADDR","nil");

      zCookie = db_text(0, "SELECT '%d/' || hex(randomblob(25))", uid);

Change them to look like this:

      const char *zIpAddr = "nil";

zCookie = db_text(0, "SELECT uid || '/' || pw FROM user where uid = '%d'", uid);

And around line 371, look for these lines:

            "   AND cexpire>julianday('now')",
            atoi(zCookie), zCookie, zRemoteAddr

Change them (just the second line) to look like this:

            "   AND cexpire>julianday('now')",
            atoi(zCookie), zCookie, "nil"

Then build a new fossil. This will make the login cookie be based solely on the user id, login name, password and project-code for non- anonymous users. (With the current code base it's based on user id and a random number and checked against your remote ip address -- it's the remote ip address that provides the limited security not the random number.)

WARNING: Do NOT do this if you're using the old, un-hashed passwords! The new, hashed passwords are a hash of project-code, login name and password. The old passwords are just the plain text password!

SECURITY WARNING: Assuming you are using hashed passwords (you are if you have a recent fossil), then your actual password is always safe. HOWEVER, if you make this change, anyone who sniffs the packets on the wire (assuming you're not using https) will be able to login as you from any machine. Furthermore, anyone who has access to your machine to examine your cookie jar will then also be able to log in as you from any machine.

You can check (from a shell prompt) to see if you have any plain-text passwords left in your repository with this:

sqlite3 REPOSITORY "SELECT login,pw FROM user WHERE LENGTH(pw) BETWEEN 1 AND 39"

You can upgrade to all hashed passwords with this command (it's safe to run it more than once, it only upgrades the passwords if they haven't already been upgraded):

  fossil test-hash-passwords REPOSITORY

NOTE: This is pretty much untested, but it's a relatively simple change but it does have security implications. However, if you're only using the fossil server from your own private corporate network it's probably okay and not too risky. To more securely allow simultaneous logins by the same user from multiple IP addresses, another table would probably be needed to store the cookies with a compound key of uid and ipaddr and then login_check_credentials would have to check that table instead of the user table (also a relatively simple change except that a schema change is involved).

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

Reply via email to