Forum: Ruby on Rails if in partial ++ getPasswort in LoginGenerator

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
tobias.jordans (Guest)
on 2005-12-11 17:36
(Received via mailing list)
Hi!

I have got two different questions:
First: How do I get the Passwort (Uncrypted) out of the LoginGenerator
(see http://wiki.rubyonrails.com/rails/pages/LoginGenerator).

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/
technoweenie (Guest)
on 2005-12-11 18:08
(Received via mailing list)
On 12/11/05, Tobias J. <removed_email_address@domain.invalid> 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
vanek (Guest)
on 2005-12-11 18:12
(Received via mailing list)
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.)
Kevin O. (Guest)
on 2005-12-11 18:21
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.
This topic is locked and can not be replied to.