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.

sebyte

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.

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.

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?

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.

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 https://ipcow.com 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.

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.

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.

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.

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.

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 1.2.3.4 in reply to 7

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.

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

sebyte

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

'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

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.

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.