RGRA portal stealth post feature

[zaimoni]

Just had an unpleasant re-surprise (was only half-awake, so didn't take full usual precautions against double-posting from Oook RGRA portal). Note that I normally use the dedicated RGRA login rather than the forum login.

I am not used to the following sequence generating a post:
* being asked to login in, so...panic; instead of filling out the login form per correct checklist on my end, hit the back button (to recover post content; panic precludes noticing that I just copied the whole post content into the clipboard just-in-case).
* Blank post composition screen comes up rather than the content of the intended post (ok)...*but* the post gets sent out anyway (bug).

The back button not only re-logged me in (not normal behavior for a web application, but can be caused by appropriate http headers), it sent out the original composed post as well (exceptionally not-normal behavior) without suggesting it had done so (bug).

This isn't the first time this has happened to me when half-awake. It just occurred to me that this combination of features would also cause double-posting for RGRA portal newbies used to standard web application back button behavior.

Does the architecture permit a quick alteration that does exactly one of the following:
* blocks posting when the back button is used?
* correctly informs the user that their post has been submitted to USENET?

Target browser is SeaMonkey 1.1.7; FireFox was forked from SeaMonkey back when SeaMonkey was the Mozilla suite.

[Nick]

Originally Posted by zaimoni

This isn't the first time this has happened to me when half-awake. It just occurred to me that this combination of features would also cause double-posting for RGRA portal newbies used to standard web application back button behavior.

I have double-posted to rgra more than once by this method, using SeaMonkey and/or Firefox (and possibly even IE).

[pav]

Well I'm not entirely sure what's going on for you. You are not allowed to fill in the post without not being already logged in, right?

So somehow the website logs you off when you hit Post button, and when you hit the back button it posts the article? I find that very hard to believe.

[zaimoni]

Originally Posted by pav

Well I'm not entirely sure what's going on for you. You are not allowed to fill in the post without not being already logged in, right?

Yes, explicit login is required befores starting to compose the post.

Originally Posted by pav

So somehow the website logs you off when you hit Post button,

The login times out on its usual 15-20ish minute schedule when using the RGRA portal login, yes. I often need longer than this to properly proofread a USENET post.

Originally Posted by pav

and when you hit the back button it posts the article? I find that very hard to believe.

RGRD, "LOS/FOV vs. Line of Fire": my first reply was double-posted with this bug.

It's not at all hard to believe. All that's required is that the back button resubmit the login form (which I can look up both how to do and prevent; I just would never design a web application to break the back button this way. I'm composing on the page generated at login) -- and that the content of the attempted post be matched with the login credentials. The form content definitely was sent in, the page requiring re-login came up in response to the failed posting.

However, doing what's expected (entering the login credentials) doesn't cause the posting. Just the back button to the page generated at login.

[pav]

I still don't get it. You log in, fill in the post, submit, get login form. At that point, you hit back - but there's no post content in that request! Only thing I can think of is hitting Reload.

Also, you surely had to confirm the warning box about re-submitting POST content, haven't you?

[zaimoni]

Originally Posted by pav

I still don't get it. You log in, fill in the post, submit, get login form. At that point, you hit back - but there's no post content in that request!

Correct; the repost on back would only have login credentials.

Originally Posted by pav

Only thing I can think of is hitting Reload.

That's not even adjacent to Back either on keyboard or GUI.

Originally Posted by pav

Also, you surely had to confirm the warning box about re-submitting POST content, haven't you?

SeaMonkey doesn't have that warning box reposting POST forms with the reload key. I have no reason to think I'd get one on a back-button induced form repost.

(Exhaustively checks options.) SeaMonkey has no obvious configuration options for this.

[pav]

So how does this happen?

You type in a post, hit submit, fill in login, hit submit, then hit back? That would lead to the post - but it's hardly sneaky, you should be getting Your post have been sent. message in any case.

Other than that, there's something weird going on with your browser. Or I don't know.

[zaimoni]

Originally Posted by pav

So how does this happen?

You type in a post, hit submit, fill in login, hit submit, then hit back?

As originally stated:
* type in post (on page generated immediately after login)
* hit submit, get login page
* hit back.

That's sufficient to get the intercepted post to reach a supported newsgroup. Which would be fine if I got "your message has been posted", but what actually arrives is the composition textarea.

[pav]

Okay, this is impossible. I'm sorry I can't fix this issue.

My only hope is this is some odd proxy/cache issue on the client side. Because as the server code is laid out now, it's not possible to have the post posted without also receiving "Your message has been posted" text...

Also my guess is that the back button is not necessary; the post is posted when you hit submit first time.

[zaimoni]

I've never seen the original post posted when actually filling out the login credentials. It should be easy enough to test safely, however.

The empty textarea for editing still comes up when doing that.