Fossil Forum

Forum posts wrongly attributed to anonymous

Forum posts wrongly attributed to anonymous

(1) By sebyte on 2019-08-27 10:01:44 [link] [source]

I just submitted a forum post about command branch current. I was logged in when I submitted it yet it was attributed to anonymous and is therefore awaiting moderator approval.

This post is partly to see if the same thing happens again.


(2) By Richard Hipp (drh) on 2019-08-27 10:07:29 in reply to 1 [link] [source]

That has happened to me too. There is a bug someplace. But it is hard to reproduce, and hence hard to fix. If you are able to provide further clues, and especially if you can get a reproduction case, that would be helpful.

(3) By Stephan Beal (stephan) on 2019-08-27 10:11:01 in reply to 2 [link] [source]

It happened to me once a week or two ago but there was no indication of what really happened. i went to reply to a post, went through the login redirect, assumed i was logged in, but ended up responding as anonymous. Whether or not i was really logged in after the redirect is unclear.

(4) By Joel Dueck (joeld) on 2019-08-27 13:19:48 in reply to 3 [link] [source]

I wonder whether IP address could have changed enough to invalidate the login in the time between when the page was loaded and when you submitted the post?

(5) By ckennedy on 2019-08-27 14:36:38 in reply to 4 [link] [source]

This could definitely be happening, especially on a Wi-Fi network you don't control. And now it makes sense to me why I have to login so often at work vs. at home. My IP address keeps changing, especially at work. At home things are much more stable, and I try to avoid having the IP address change by having longer DHCP leases. At work, things are optimized for quick re-use of the limited IP pool so if the computer goes to sleep or disconnects in any way, you get a new IP address.

(8) By Joel Dueck (joeld) on 2019-08-27 15:00:46 in reply to 5 [link] [source]

At work, things are optimized for quick re-use of the limited IP pool so if the computer goes to sleep or disconnects in any way, you get a new IP address.

Are you talking about logging in to a Fossil repo served on your LAN? Or about one served from a public web server? Because having short DHCP leases would only affect your LAN IP, which a Fossil instance on a public web server would never see (it gets NATed by your router). Going to a site like will show you your IP address as it would appear at that moment to a public web server.

If you are talking about a Fossil repo being served on your LAN, you should have whoever administers it change the “IP address terms used in login cookie” setting on the /setup_access page in the web UI. If the repo is only accessible inside a non-public LAN, there’s probably no reason for it to be checking the IP address at all.

(9) By ckennedy on 2019-08-27 15:11:52 in reply to 8 [link] [source]

At work, I am the DHCP admin, and I give myself a static address, so I don't have this problem. But I only control the wired side. The Wi-Fi side is controlled by a master agency (don't ask - silly security policies) and they do some very odd things in the name of "security". My problem with logins I was talking about was on the forum here. Some times my login holds for nearly a week, other times less than an hour. I also have issues if I login from different computers. They invalidate the login on the other computer.

I think wyoung and drh have hit on the issue though. IPv6 is coming, and I for one am not looking forward to it.

(6) By Warren Young (wyoung) on 2019-08-27 14:52:22 in reply to 4 [source]

IP address could have changed enough to invalidate the login

I thought that couldn't be correct, since I use a cable Internet service which keeps IP addresses constant over the course of years, and it's happened to me, too. On investigating, I think I know why it happens anyway.

First off, it looks like the code for this is written to assume that the first two octets of an IPv4 address are always stable for the "same" user, which is a dodgy assumption. Ideally you'd want to use the netmask to determine this instead, but since I don't know of a way to get an Internet provider's netmask by source IP, let's just temporarily chalk this up as "best effort solution."

(The client can't provide the netmask since that may be on the client side of a NAT. What we care about is the Internet-facing net's mask.)

I bring all of this up because both my home and work use the same cable Internet provider, and we're just a few blocks away, but our stable public IP addresses differ past the first octet! This is why I use two logins here, wyoung and wyetr, so I don't keep getting bounced out every time I switch locations.

Yet I do occasionally get bounced out anyway, despite keeping separate accounts per location, more often at work. And I think I know why: IPv6.

If you look in /access_log, drh, you will see that you've logged in from a bunch of IP addresses, and more of them are IPv6 than are IPv4. Since the ipPrefix() function in login.c assumes there must be a dot in the address string provided by the CGI layer in REMOTE_ADDR, it will consider any change in an IPv6 address to be significant. It will also consider a switch between v4 and v6 significant.

You may wonder at the last sentence. How can that happen? Yet I've just checked the security logs at a service I use that keeps them, and it shows my IP address toggling between v4 and v6 occasionally! This is apparently a thing my Internet provider does. Maybe yours does, too, drh.

Solution: Keep a list of validated IP addresses for a given user, expiring old ones according to the same sort of timeout as is used on the cookie, so that the user must log in if they don't present one of the known-good IP addresses before it's considered too old to believe any more. The notion of "same" must change to accommodate IPv6 addressing schemes.

(7) By Richard Hipp (drh) on 2019-08-27 14:58:39 in reply to 6 [link] [source]

Solution: Keep a list of validated IP addresses for a given user,

Perhaps a better solution is to simply stop requiring that logins stay on the same IP address. That requirement dates from an era when TLS was much less pervasive than it is today, and was motivated by a desire to prevent connection hijacking. But it isn't very effective at that, and TLS is a better solution. So perhaps the time has come to deprecate the use of IP address as part of the login credentials.

(10) By Warren Young (wyoung) on 2019-08-27 15:12:53 in reply to 7 [link] [source]

A lot of the high-end Internet application service providers (e.g. Google) do some kind of client fingerprinting, which may include the IP address, so I think we can infer that it's still a good idea.

It makes sense to me: if someone shows up with an IP that has never before been seen from that client, we should at least make sure they can provide the password again. But once they do, simply changing IP shouldn't be enough to be skeptical, if they're just returning to an IP that we already decided was okay to pair with that user name.

I assume you have a Google account. Click your user icon in the corner of a Google page while logged in, go to Account Settings, Security, Your devices, Manage devices. From there you can get a list of IP addresses and other client info that Google uses to decide if you are you.

I'm not saying we need to go to the same extent, but I don't see why we'd need to learn our own lessons on security from scratch. Someone else has already taken the arrows. Let's learn.

(13) By sean (jungleboogie) on 2019-08-27 15:29:27 in reply to 10 [link] [source]

To Warren's point, I do see that it could be beneficial to list known IP addresses for a given user to a given user in their account page. In the event something mischievous happens, a user could revoke another session and force a logout on that account from that IP.

I have no idea how that would be implemented or how often it would need to actually be used.

(11) By sean (jungleboogie) on 2019-08-27 15:16:31 in reply to 7 [link] [source]

I do think your alternative solution is probably something to consider over a rotating list of known IPs for a given user. I'm logged into reddit at work and at home; Reddit probably keeps track of both of these IP addresses, but doesn't force a logout from one device to the other just because the IP (and ISP) are different.

On other forum software, I've seen my IP address logged and displayed for my posts and hidden from others, except moderators. Maybe what can be improved is logging for moderators and authors but not blocking.

For instance:

(10) By wyoung on 2019-08-27 15:12:53 from in reply to 7

(12) By ckennedy on 2019-08-27 15:20:26 in reply to 11 [link] [source]

This is about the time when I wish user certificates had actually become a real thing for everyone. Then as long as I provide the correct certificate we are done.

Oh well. That boat has long since sunk.

(14) By anonymous on 2019-08-27 16:41:06 in reply to 3 [link] [source]

[I] ended up responding as anonymous.

Writing this post, I previewed it while logged in, then deleted the Fossil cookie and previewed it again. The only indication that I was now logged out was the 'Login' link in the top right corner of the page. This is very easy to miss.

Perhaps the Submit button should read 'Submit (as sebyte)' or 'Submit (as anonymous)'. No one would miss that, and they would then be able to choose whether or not to login in again.


(15) By sebyte on 2019-08-27 16:56:06 in reply to 14 [link] [source]

Of course, this assumes the poster's IP address hasn't changed (if that is the cause) between the last preview and final submission.

Perhaps the only robust workaround is a confirmation page that reads 'Please confirm that you wish to post to the forum anonymously'.

(16) By sean (jungleboogie) on 2019-08-27 18:36:06 in reply to 15 [link] [source]

'Please confirm that you wish to post to the forum anonymously'.

I haven't posted anonymously before, but just below the "Enter Reply:" text, it does show

From: jungleboogie

So it looks like there's two ways to verify who you're posting as:

  • Look in top right corner

  • Look above reply box

(17) By Richard Hipp (drh) on 2019-08-27 18:44:03 in reply to 16 [link] [source]

Fossil should verify this automatically. If you start out composing your post while logged in (and Fossil will warn you and prompt you to log in if you are not) then it should not let you submit the post as anonymous.

That does not fix the unexpected-logout bug. But it does soften its impact.

(18) By sebyte on 2019-08-27 19:03:50 in reply to 17 [link] [source]

If you start out composing your post while logged in [...] then [Fossil] should not let you submit the post as anonymous.

I was going to suggest this but thought it best to focus on the simplest, most robust workaround that can be employed in the mean time.