![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
afunaThe form at the bottom of the comment notification email contains a comment-specific hash, which authorizes the person posting the form as the user the notification was sent to. This is useful for replying if you're not logged in, or if you're logged in to another account (multiple journals, etc). But it also means that if you forward the comment notification email to someone else, they can reply as you for that particular comment.
This came up in Bug 314, after noting that one fix to allow OpenID users to reply to comments from the email had the side effect of removing the existing behavior -- the person posting the comment would have to be currently logged into the same account as the one which received the emailed notification for the comment to be posted.
D says this is a good thing! And I kinda agree, because it's good to close up the security hole. But I'm torn because I also really like the convenience of the existing behavior.
So, throwing ideas out there for how we can handle it:
a.) make it clear that the authorization is tied to the comment form, and that forwarding the notification email with the form to someone else will allow them to reply as you to that comment. Do it on the form itself, either subtly (changing the "post" button to "post as $user"), or by adding some kind of text; document this behavior somewhere people can easily find it.
This is pretty easy to do, but may not be effective, and may cause worry to have warning text.
b.) close the hole by showing an error message if the account you're trying to comment as does not match the account you're logged into.
Also easy to do, but pretty drastic.
c.) close the hole by forcing you to authenticate as the commenting user if it does not match the account you're logged into (More details, from Sophie).
I like this idea because it's not as drastic as option (b), and it looks relatively simple to implement. But it could also get annoying to have to reauthenticate all the time, depending on how often you'd have to switch accounts this way.
d.) provide another way to reply, perhaps by replying to the email directly, instead of using a form. (More details, from me).
I'm in favor of this idea because it solves a few other problems -- means you can always reply from the notification if you have access to an email client but not a browser (phones, DW blocked, composing comment replies offline), or if you're using one of the clients which disallows POST requests (off the top of my head, Thunderbird won't allow this). Also means no need to switch logins in the browser.
But it's the most drastic change to implement, and I don't know how much additional load it would cause to set up something that can receive email, parse it in a timely fashion, and post the comment, plus the time we would need to spend to build something from scratch.
e.) Other ideas?
This came up in Bug 314, after noting that one fix to allow OpenID users to reply to comments from the email had the side effect of removing the existing behavior -- the person posting the comment would have to be currently logged into the same account as the one which received the emailed notification for the comment to be posted.
D says this is a good thing! And I kinda agree, because it's good to close up the security hole. But I'm torn because I also really like the convenience of the existing behavior.
So, throwing ideas out there for how we can handle it:
a.) make it clear that the authorization is tied to the comment form, and that forwarding the notification email with the form to someone else will allow them to reply as you to that comment. Do it on the form itself, either subtly (changing the "post" button to "post as $user"), or by adding some kind of text; document this behavior somewhere people can easily find it.
This is pretty easy to do, but may not be effective, and may cause worry to have warning text.
b.) close the hole by showing an error message if the account you're trying to comment as does not match the account you're logged into.
Also easy to do, but pretty drastic.
c.) close the hole by forcing you to authenticate as the commenting user if it does not match the account you're logged into (More details, from Sophie).
I like this idea because it's not as drastic as option (b), and it looks relatively simple to implement. But it could also get annoying to have to reauthenticate all the time, depending on how often you'd have to switch accounts this way.
d.) provide another way to reply, perhaps by replying to the email directly, instead of using a form. (More details, from me).
I'm in favor of this idea because it solves a few other problems -- means you can always reply from the notification if you have access to an email client but not a browser (phones, DW blocked, composing comment replies offline), or if you're using one of the clients which disallows POST requests (off the top of my head, Thunderbird won't allow this). Also means no need to switch logins in the browser.
But it's the most drastic change to implement, and I don't know how much additional load it would cause to set up something that can receive email, parse it in a timely fashion, and post the comment, plus the time we would need to spend to build something from scratch.
e.) Other ideas?