My KDE hass the odd (yet quite smart) technology of receving a page twice to find the mime-type. If i knlick a link in my email program, kmail calls that url, defines the mimetype and the opens it in teh approporate application.

This gives difficulties with the one-time reset password urls. I never get to see the status message, nor do i know how/if the password is reset. All I see is an access denied message.

I do not know a solution, but think something in the line of a special short-time-session might be a solution.

Comments

I don't know what is smart about that technique. I am inclined to won't fix it.

Title:Reset password link "breaks" in KDEsend headers first (on password reset pages)

I renamed this issue , becuase after some investigation this is the case:

A lot of systems will determine what application to use for a file based on the mime type. Less smart systems will simply open anything starting with http:// in a browser. But smarter systems like KDE pull in the headers to determine the mime type and open the file in the appropriate application.

Drupal is not too smart in handling this. It loads, processes and builds a complete page, before sending it to the server/user. Not only in the case of KDE (mime type detemination) does this cause trouble. Google, for example checks the headers too to see if it needs to be (re) indexed. We now build that complete page, even if google (or KDE) terminates the connection, because It got enough info.

Ah, that makes much more sense now. No idea if we can fix it, though.

Well, I'm for supporting KDE but this is a difficult one...

The thing is the password reset page first updates the timestamp so the login can be used only once, and then it uses drupal_goto(user/x/edit), sending a redirect.

So maybe we could update the timestamp on that second page only but would it fix the problem?. I mean, I dont know exactly what happens with drupal_goto and the REDIRECT header, would it stop there or would the second page actually be produced?

Another idea would be updating the timestamp on the exit hook, which I think runs only after the page has been sent, doesnt it?
And the last one could be to get rid of 'one time logins' as it is valid only for a short period of time anyway...

Btw, I'm not using KDE bug gnome, and I didnt get this problem with Evolution + Firefox, so any way I can test this without using KDE?

Okay. Forget all my mumbling about KDE and Konqueror. I only used those as an example!

Any application or any system that:
* investigates the headers of a file
* then fires the appropriate app associated with that filetype to open this will run into this issue. I think OSX had some trouble. And I have heard reports of some Windows users too. The problem can lie anywhere. Even a smart mailclient, that wants to find out what program it should call for a certain url
A png should be opened in an image viewer, while a html file must be viewed with a browser *no matter what the location is*
our "rather dumb" systems often just call the webbrowser for anything that starts with http:// eventhough we have much better image viewers on our system. Some 'smarter' systems choose to investgate the headers first.

They cause the current on-time urls to be used already, for they are called, in order to investigate the headers.

Bèr

Title:send headers first (on password reset pages)password reset is not working in some cases
Priority:Normal» Critical

We've had a number of people complain on infrastructure@drupal.org that they werent able to log in using the "one time login" link. So I think this needs fixing and I've set it to "critical".

I don't think we can solve it by sending different response headers. We should maybe make the "one time url" not a "one time url". It should work again, if you access it again within the 24h timeout period. Or we introduce another timer that counts the time from first accesing the url and maybe only runs for five minutes.

If we focus on the header generation, then we would need to code deep into Drupal.

Indeed making this a time based thing is the best option. 24 hours (or much less) after the url was used first, it should expire.

And when it expored, we should prompt a message telling people that. "Your one time url is no longer valid"

Can the 24hr limit be accomplished by changing line 1035 from checking
$timestamp < $current
to
$current - $timestamp > $timeout
as is done on line 1031?

Then the password will be randomly reset as many times as they want within a 24h period?

I would stick to five minutes or less... I think leaving a 24 hour password reset open is asking for trouble...
Then again you could always kill the link once a password is chaged in user_save?

Status:Active» Needs review
StatusFileSize
new3.92 KB

Hi,

I think I've found a solution that fixes this problem keeping it a one-time login -which I like because of the extra-security it means.

This patch adds a confirmation screen before the user actually logs in, with a 'Log in' button and providing some extra information. (+feature).

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new3.23 KB

I cleaned up your patch a bit. But its a great idea, really.

Status:Reviewed & tested by the community» Needs work

That /1 isn't a very ellegant URL. We don't glue words together ($dologin). Use theme('placeholder').

StatusFileSize
new3.38 KB

Updated with placeholder and nicer url '../login'

I've applied and tested the one-time-login-confirmation patch and it seems to work as advertised.

Djun

Wouldn't it be nicer to make this two separate URLs? The URL grows unwieldy:

user/reset/$uid/$timestamp/$hashed_pass/login

Attaching the 'login' at the end is somewhat hackish. It's a quick fix, but not necessarily the most elegant fix.

Well Dries, may be, but then we'd need one more menu entry and one more function....

What you suggest is closer to the very first version of the patch, isn't it?
But I like chx's idea of having it all in a single function. Moreover, I think the current one is quite straight forward, I even see some beauty in the simplicity of it ;-)

Status:Needs work» Fixed

Reconsidered. Committed to HEAD.

Status:Fixed» Closed (fixed)