It's not obvious whether or not CRAM is activated.

I think this would be best offered as an option. Security through obscurity isn't always a good idea but it's understandable that some people wouldn't want to advertise the use of this module on their sites.

selmanj, have you noticed that the password field is acting differently since the latest 5.x-dev release?

When the login form is submitted, the obscured password fills up the password field. It's a subtle effect that I like, though I'd still like to have an option to disable the visible effect.

@christefano

Yeah, this was a result of some changes I made to the code. Rather than hiding the username+password to show a "Logging in..." method (which was really there to hide the password field while an AJAX request was done to get the nonce, so the user couldn't mess with the values until the js had completed), the code now has the nonce directly in the form, so there is no need for AJAX. The reason the password field suddenly fills in is because it's actually being replaced with a hmac of the password typed in before being transmitted.

I'm not sure of the javascript required to hide this sort of effect... Is there any way to make changes to the form's value but not let it change in the user's view?

Ahh, so the password field is filling up with the hashed password. I thought it was a security feature designed to obfuscate the number of characters in a password but it's actually a side effect!

Since my last post, three people I work with have told me they don't like this effect. Two aren't computer savvy and were completely convinced that the visual feedback meant that they entered the wrong password.

Without looking at the code I'm not sure how to toggle this effect or disable it. I'm not sure when I'll have a chance. My first thought is that CRAM could display the "logging in ..." message in the password field but I'm not sure that's the most elegant solution.

Not to be pedantic, but what you're discussing now sounds, to me, like a different bug than what this issue is really about. :)

And to continue with my different comment, CRAM for both D5 and D6 shows either Click here to revert to plaintext login. or Click here to log in using CRAM secure login. Does it need to be made more obvious that it's using CRAM when it says revert to plaintext?

Well, if you have javascript turned off, you still get the message 'click here to revert to plaintext'. It would be nice if there was absolutely no way you could attempt to login without having javascript turned on (ie, if CRAM is enabled, don't render the submit button, and rely on the javascript rendering the submit button in the correct place). That way, users would never be able to submit their password mistakingly in the clear (unless something has gone very wrong)

Now I understand the "Not to be pedantic" comment. I didn't actually see the "Click here to" messages until updating to the very latest version. Attached is a patch to make the messages translatable.

@christefano: Oops. Nice catch. Those are things I thought I was good at finding. :) I've committed the patch even if it really should've (also) been an issue of its own.

@selmanj: Alright, I see your point. No idea right now of what to do though.

I wondered about posting the patch as a separate issue but it seems to me that the "Click here to" strings are what make it obvious whether or not CRAM is activated. :) Thank you for pointing out what you prefer, though. It's easy for me to forget how issue queues can be different from project to project.