Closed rubenmoor closed 3 years ago
This can be fixed by using unsafeShowPassword
just before sending it.
A documentation addition is planned in #28, I think that might help you?
So I reverted back from Password
to Text
for my client representation of the plain-text password. Thanks for the hint, this all works fine.
I like to point out, though, there is nothing unsafe per se about instance ToJSON Password
. And having the Password
type in my client as well as on the server would be more consistent.
Given how easily a Password
could be embedded in a record type and just end up in error messages/logs/responses/etc. we, at least for now, decided to make it invalid, just to make the conversion intentional for users.
As the example in #28 shows, having a LoginForm Password
and turning it into a LoginForm Text
using unsafeShowPassword
is a very conscious decision to "unpack" a password and use it as plain-text. This makes it obvious what's happening from a security perspective and as such gives more confidence that a password will not leak unless an unsafeShowPassword
is used.
You can always opt to just use Text
over Password
, of course, though I'd disadvise it on principle, but I can imagine a client taking the Text
from the end user and pretty much immediately sending it to the backend would not benefit greatly from wrapping it in Password
and then unwrapping again before sending.
As @Vlix said, password
doesn't really have any consideration for client-side use.
However, for those using GHCJS, it could make sense to create a library like password-instances-client
or something that contains helpful instances?
I've never really worked with GHCJS, so I'm not sure what sort of instances would make sense here, other than ToJSON
.
I think this issue has been sufficiently illuminated. There is nothing else needed than the obvious ToJSON instance.
I work with reflex. I send the plain-text password from the client to the server and thus the missing
ToJSON
instance is too restrictive.