6 ms·

If you use javascript to extract the token from the URL then you can simply pass it via the hash ("fragment") part of the URL. The hash portion is only interpre

If you use javascript to extract the token from the URL then you can simply pass it via the hash ("fragment") part of the URL. The hash portion is only interpreted by the user agent and never sent to a server (see https://tools.ietf.org/html/rfc3986#section-3.5 https://tools.ietf.org/html/rfc3986#section-3.5). This is how we solved it at paperhive.org.

oneeyedpigeon 10y ago
Obviously, the drawback is that you've introduced a javascript dependency to a core function which definitely doesn't require it. Having said that, I notice that paperhive.org renders an entirely blank page if javascript is unavailable, so I guess the password reset is the least of your concerns in that scenario.
- angry-hacker 10y ago
  And what percentage of the users have javascript disabled? Objectively you have bigger concerns when you run a site than 10 people who have js disabled.
  - oneeyedpigeon 10y ago
    Definitely more than zero. It's not just a case of javascript being disabled, either - there are many other reasons why it might be "unavailable", which is why I used that word. Of course I'm not suggesting you're not allowed to use any javascript on your site, or even that you should only use it when it's strictly necessary, but if it's entirely unnecessary and you don't engage in best practise by, for example, using progressive enhancement, then that's something that could be improved.
  - tomjen3 10y ago
    I used to think so, but information sites probably needs to work without javascript, if only for google bot.
- VertexRed 10y ago
  It's 2016, everyone has JS enabled. The ones that don't are most likely bots (now even that's changing thanks to projects like phantomjs).
  - dmm 10y ago
    >everyone has JS enabled. Using an addon like NoScript it's possible to selectively enable javascript per domain. When a website doesn't work without js I am forced to decide whether it's worth enabling js for this site. Very often I decide it's not worth it and I never use that site again.
    - spdustin 10y ago
      You and I both. Remember, however, that you and I are not a representative sample of the general population of web users.
      - andrewflnr 10y ago
        That would be meaningful if we were talking about some optional UX feature, but this is security. Does having a non-representative browser config mean we don't deserve security? I think not. Security has to work without JS.
        spdustin 10y ago
        Why wouldn't it just <noscript> an input field to enter the token
    - grimmdude 10y ago
      Can I ask your reasoning in doing this?
      - marklgr 10y ago
        Why should we trust any website and execute their JS code on our machine? What about privacy, if they decide they can track us and sell the information to whoever they want? And even if they're "legit", what about the 3rd parties they might trust wrongly?
vbezhenar 10y ago
For users without JavaScript it's reasonable to include a plain form and send token in plain text as well, so user can copy-paste it into a form and reset his password.
derekprior 10y ago
This has been suggested numerous time since I published. I had not previously considered this solution and I think it's a fine solution for people to make if they know the tradeoffs. It's worth noting there are a number of reasons this JavaScript could possibly not execute beyond people who have JS turned off. I've seen a number of sites fail to execute JavaScript when an Ad Blocker is run, for instance. In this case, there are a number of server side fixes available that wouldn't require any JavaScript. They're not terribly complicated and will always work. For that reason, I'm still comfortable with the server side fix, but think the JS fix is a decent alternative.
mkagenius 10y ago
You are assuming that 3rd party javascript is not taking the whole URL including the hash part and sending it for analytics. I have seen at least one analytics company do that.
morgante 10y ago
Wouldn't any (third-party) JavaScript on the page still have access to it?
- fredsted 10y ago
  They would also have access to everything else, including the entered password.
  - morgante 10y ago
    Right. The scenario I'm considering is not a hostile attacker but simple an overzealous analytics script which also tracked hash strings. Heck, since some sites used to do AJAX navigation that way it wouldn't surprise me if some analytics services were configured to track hash strings.

oneeyedpigeon 10y ago

Obviously, the drawback is that you've introduced a javascript dependency to a core function which definitely doesn't require it. Having said that, I notice that paperhive.org renders an entirely blank page if javascript is unavailable, so I guess the password reset is the least of your concerns in that scenario.

angry-hacker 10y ago
And what percentage of the users have javascript disabled? Objectively you have bigger concerns when you run a site than 10 people who have js disabled.
- oneeyedpigeon 10y ago
  Definitely more than zero. It's not just a case of javascript being disabled, either - there are many other reasons why it might be "unavailable", which is why I used that word. Of course I'm not suggesting you're not allowed to use any javascript on your site, or even that you should only use it when it's strictly necessary, but if it's entirely unnecessary and you don't engage in best practise by, for example, using progressive enhancement, then that's something that could be improved.
- tomjen3 10y ago
  I used to think so, but information sites probably needs to work without javascript, if only for google bot.
VertexRed 10y ago
It's 2016, everyone has JS enabled. The ones that don't are most likely bots (now even that's changing thanks to projects like phantomjs).
- dmm 10y ago
  >everyone has JS enabled. Using an addon like NoScript it's possible to selectively enable javascript per domain. When a website doesn't work without js I am forced to decide whether it's worth enabling js for this site. Very often I decide it's not worth it and I never use that site again.
  - spdustin 10y ago
    You and I both. Remember, however, that you and I are not a representative sample of the general population of web users.
    - andrewflnr 10y ago
      That would be meaningful if we were talking about some optional UX feature, but this is security. Does having a non-representative browser config mean we don't deserve security? I think not. Security has to work without JS.
      - spdustin 10y ago
        Why wouldn't it just <noscript> an input field to enter the token
  - grimmdude 10y ago
    Can I ask your reasoning in doing this?
    - marklgr 10y ago
      Why should we trust any website and execute their JS code on our machine? What about privacy, if they decide they can track us and sell the information to whoever they want? And even if they're "legit", what about the 3rd parties they might trust wrongly?

vbezhenar 10y ago

For users without JavaScript it's reasonable to include a plain form and send token in plain text as well, so user can copy-paste it into a form and reset his password.

derekprior 10y ago

This has been suggested numerous time since I published. I had not previously considered this solution and I think it's a fine solution for people to make if they know the tradeoffs. It's worth noting there are a number of reasons this JavaScript could possibly not execute beyond people who have JS turned off. I've seen a number of sites fail to execute JavaScript when an Ad Blocker is run, for instance. In this case, there are a number of server side fixes available that wouldn't require any JavaScript. They're not terribly complicated and will always work. For that reason, I'm still comfortable with the server side fix, but think the JS fix is a decent alternative.

mkagenius 10y ago

You are assuming that 3rd party javascript is not taking the whole URL including the hash part and sending it for analytics. I have seen at least one analytics company do that.

morgante 10y ago

Wouldn't any (third-party) JavaScript on the page still have access to it?

fredsted 10y ago
They would also have access to everything else, including the entered password.
- morgante 10y ago
  Right. The scenario I'm considering is not a hostile attacker but simple an overzealous analytics script which also tracked hash strings. Heck, since some sites used to do AJAX navigation that way it wouldn't surprise me if some analytics services were configured to track hash strings.