HFS cookie issues on Rename in the default template? FIXED in 2.3f

[skb]

I see from reading the default template that HFS uses a "session ID" cookie named HFS_SID for its rename and comment actions, but I don't really get how this cookie works or what it accomplishes. This cookie is involved with rename operations because in the "ajax" function, there is:

Code: [Select]

data.token = getCookie('HFS_SID');
but I'm not clear where or how that cookie gets set.

The problem I'm having is that sometimes (but frequently enough to be annoying) the cookie apparently gets messed up, and the rename command fails with "Error: bad session".  I've not yet been able to work out what circumstances cause this situation to occur, but once it does, then it continues until I clear cookies from my browser, and restart the browser.

I think the issue may come up when I switch between two different instances of HFS, e.g. when I work with a copy on localhost during development, and also with a "production" copy on a host out on the net, where I have the same username on both instances. (If this is the only trigger, then I don't have to worry about actual users hitting this cookie problem, but I can't tell.)

It also seems more likely to occur if I have not used the server for several days, but again, I can't tell if this is actually a trigger, or just coincidence. (Perhaps my session cookie "expires" if I don't log in for a few days, and then I get this when I next log in?)

Or, is there an issue if the server is restarted between my logins?

I'd like to understand the situation enough to know what circumstances actually cause it, so I can know if it might actually crop up for real users. So far, I have not been able to find that pattern that reproduces the "bad session" error on rename or comment.

Can anyone explain how cookies are supposed to work, and how they interact with the rename process, and what the HFS_SID cookie is about?

It gets tested (I think) with the following macro:

Code: [Select]

check session=break|if={.{.cookie|HFS_SID.} != {.postvar|token.}.}|result=bad session

but again, I don't really know what that does, or when, or why.

Thanks for any clues!
Steve

[rejetto]

even if i made it, it's not easy to remember now, but this is what i can tell you from a quick look:
- the cookie is set not by the template, but by the program itself
- apparently the only way the template uses the session is to avoid some security problems
- i expect you to have a 'bad session' if you restart the server. In this case i also expect that reloading the page in the browser should be enough to solve it. Isn't it so?

[skb]

Thanks Rejetto,

In fact, I often restart my development server when updating my template, and only rarely get this error message. So, not directly caused by a server restart. Perhaps a server restart in conjunction with a previous cookie expiring?

Also, once it does occur, it persists through browser restarts, page reloads, etc. That is, if I restart the browser, then when I go back to my server, I have to log in again (as expected), and after login, Renames will still fail with the same error about a bad session.

Not sure if a server restart after the error occurs will clear the situation. I don't think so, but not 100% sure I've tried this explicitly.

Clearing cache in the browser doesn't help, with or without a browser restart; this was explicitly tested.

Clearing cookies in the browser does resolve the issue.

(Again, I don't have reports of it happening in the field, though I warn users of the possibility in my instructions. It may be just a side effect of me running sites with the same template on two different servers, one at localhost on my dev machine, and one online at a global static IP, with the same logins on both, and my browsing back and forth between the two sites. The actual users use their single production site only, not two different ones.)

Locally, I've had it happen sometimes with both Firefox and Chrome, on Win7 and Win8 clients, and with a Win7 and Win8 server. Also, it happens sometimes to the localhost server, and sometimes to the remote server. But, I've not found the pattern that will reproduce it.

I'll keep trying to get a reproducible error, as I don't think we can hope to fix it without that. I'm seeking background on the function of cookies to guide me in finding a reproducible cause.

Cheers,
Steve

[rejetto]

I don't understand why the cookie doesn't go away. Chrome says it expires after the "session", and that's what i think is when you restart the browser.
As a workaround, try edit the template, and replace this line
        if (res != "ok")
            return alert("{.!Error.}: "+res);

with
        if (res !== "ok") {
            alert("{.!Error.}: "+res);
            if (res === 'bad session') {
                delCookie('HFS_SID');
                location.reload();
            }
            return;
        }


If the solution works, then i'll tell you how to avoid editing the template, as it causes you to lose future updates of the template.

[skb]

Sorry, been away for awhile. I came back because I hit this bug again on Firefox but not Chrome (but Firefox is the browser I'd used more in the past for HFS access, so it was more likely to have old context.)

I'll put your suggested fix in my template now, but it will probably be a while before the bug gets triggered again.

When it happened today, I tried deleting the HFS cookie with Firefox's "File > Preferences... > Privacy > Remove individual cookies", and then restarted my browser, and this did not help. Then I deleted the cookie again, restarted the server and restarted my browser, and it still didn't help. I tried Firefox's "clear everything for the past hour", and it didn't help (because I think whatever was causing the problem is from a few weeks ago.)

Finally, I had Firefox clear all of its saved stuff from any time (History > Clear recent History... ; and then put a check by every item, and set "Time range to clear" to "Everything". Then browser restart, and now a rename worked.

I'd been running HFS regularly back when I first posted, but then shipped a version, and shut down my test copy. So, my server has been down for a few weeks, though the actual users have not reported any issues with theirs.

Today I fired up my copy again, and hit the bug when I first logged in. So, whatever bit of history was confusing Firefox is probably several weeks old.


Anyway, sorry to leave this thread hanging so long. I'll install your patch and see if the bug comes up again.

[rejetto]

no problem.
In the while i decided to include this patch in the next release, for now.

[skb]

Fixed by version 2.3f  (Via changes to the standard hfs.tpl file included in this version).

I had the problem recur despite the workaround suggested earlier in this thread, but upgrading to version 2.3f and patching my stripped-down version of the hfs template with the changes to the cookie handling from the new hfs.tpl made the problem go away.

Thanks for the fix, Rejetto!

Steve