If in partial ++ getPasswort in LoginGenerator

Hi!

I have got two different questions:
First: How do I get the Passwort (Uncrypted) out of the LoginGenerator
(see Peak Obsession).

We need this to make an “update your data”-screen with the right
passwort written inside. Otherwise the update-function won’t work
(together with our validation).

Second: How can I do an if inside a partial?
As a workaround for the problem above we wanted to view the
password-fields that are written by a partial only if the action “new”
runs the partial, not the action “update”.
Is there a way to check wich action ran the partial?

Thanks
~Tobias


Weblog: http://flyingsparks.wwwfiles.de/

On 12/11/05, Tobias J. [email protected] wrote:

Second: How can I do an if inside a partial?
As a workaround for the problem above we wanted to view the
password-fields that are written by a partial only if the action “new”
runs the partial, not the action “update”.
Is there a way to check wich action ran the partial?

Thanks
~Tobias

The Login Generator uses SHA1 to encrypt the password, which is a one
way encryption scheme. If you want users to get their password back,
you have two options:

  • use plain text passwords
  • use a reversible encryption scheme. My acts_as_authenticated plugin
    has an example of this. But, it doesn’t provide any better security
    than plain text since the info to decrypt is all right there. It just
    protects against accidental disclosure to admins viewing the database.

Here’s an if loop you can use to check the controller action:

<% if controller.action_name == ‘new’ -%>
It’s new, it’s xoo!
<% end -%>


rick
http://techno-weenie.net

Rick is correct in that once the password is salted, hashed and stored
it
is no longer accessible in plain text.
But you really don’t need it anyway.
Just ask the user to reenter it one more time right before you do the
update.
This is actually a nice security measure.
(I wouldn’t recommend using plain-text passwords.)

  1. yeah, you can’t get the password back from the SHA1 scheme unless you
    save it in the table, as Technoweenie says. Personally, I think it’s a
    bad idea anyway.

2.If you use the standard scaffolding to edit a user record, you are
going to be in trouble. The scaffold will put the encrypted password
into the appropriate field and when you submit it, it will re-encrypt
the password based on the already encrypted password. Net result is a
random password being saved. The model is set up to ignore the password
if it is blank, so just set the password field to “” before rendering
the form.

FYI, you can reset the password manually in the database using
phpMyAdmin.

  • Browse the record for the user.
  • select the SHA1 function for the password column
  • enter ‘change me–new password–’ in the field (assuming you haven’t
    changed your salt)
  • submit.

Footnote, updating attributes for the user model will muck up your
password in the same way. At least in development mode. I think
ActiveRecord assumes the entire record changes then and writes
everything back… resulting in a re-hashed password.

I haven’t tested it, but it might be possible to override the password
attribute functions to return a blank, and then write a different one to
read the real, encrypted value. The authentication routines could be
modified to use the new one. That way the scaffold and other routines
would not be able to retrieve the encrypted value and thus can’t rehash
it.