Search

C'mon Michael, you know you enjoy a challenge. If everything is too easy, you might not stick around!

Haha, Allen, you may be right with that. I have become a bit nerdy. :-)

I am using the Members Forms and really love it !

But when I use the Activation template "members-form-activate-account", the name of my activation field is not displaying.

Here is the html output :

  <form action="" method="post">
<div class="input">
<label for="fields-username">
Username
</label>
  <input id="fields-username" name="fields[username]" value="animal" type="text">
</div>
<div class="input">
<label for="fields-">
</label>
  <input id="fields-" name="fields[]" type="text">
</div>
<div class="input submit">
  <input name="action[members-activate-account]" value="Activate Account" type="submit">
</div>
</form>

So as "fields-activation" is not defined, when I try to activate from the frontend i get Activation is a required field. and the event fails.

Any idea how to fix it ??

Thanks :)

Please check your configuration file. There should be an activation field section:

<field type="activation" handle="activation">
    <label>Activation Code</label>
    <errors>
        <activation type="missing" message="Activation Code is a required field."/>
        <activation type="invalid" message="Activation error. Code was invalid or has expired."/>
        <activation type="invalid" message="Member is already activated."/>
        <activation type="invalid" message="Member is not activated."/>
        <error type="invalid" message="No Activation field found.">'Activation Code' is a required field.</error>
    </errors>
</field>

Do you find such a section?

P.S.: Search for type="activation".

I update my config from the git repo and it's ok now ! Thanks again !

I have updated Members Forms on GitHub. After thinking about the password field logic, I noticed that is potentially dangerous to ever use postback values on password fields. (Just think about it: the password value will be in the HTML page source! So in certain situations it would be enough to make the user leave his computer in order to get his password.)

So now, if anything is wrong with a password or password confirmation field, both fields will be rendered empty.

This also means that the class="invalid" rendering has to be changed a little. In order to always mark both password fields as invalid, you have to add more errror messages to the configuration file. I updated the German and English example files accordingly (and hope to receive a pull request for the Russian file soon).

As soon as the russian config file is fixed, I would like to release this as 1.0 Beta.

Noooo :-( I hate it when password fields lose their values. Even if it's in the source, why is this a security risk? It's no less secure than the unencrypted POST stored in the browser request. Could this perhaps be an option in the XSLT?

Just think about it: the password value will be in the HTML page source!

I don't see a problem with this, after all it's the users computer.

So in certain situations it would be enough to make the user leave his computer in order to get his password.

I don't understand what you mean here.

I'm with Nick on this one. I hate it when any website makes me re enter any value.

I also hate it when fields lose their values. In the password case I consider it a security risk because if a page with the postback value is left open (while the user fetches some coffee), you can get the password by simply looking at the page source.

It's no less secure than the unencrypted POST stored in the browser request

Are you sure? Can you retrieve a POST value somehow (e.g. read it from the browser cache in the filesystem)?

I wait for more feedback on this. (Brendan? Huib? Craig? Allen?)

P.S.: With questions like this one, I often ask how GitHub does it. (I think they have built an amazingly good application). Try their login form with invalid data. They don't send back passwords (but the username).

When users login, they can do so either via http or https. In the latter case, the transmission between the client and the server is encrypted. That said, this is probably not going to be the norm in most implementations of the members extension.

Sending authentication data to the server in the clear is a potential point for exploitation. If the response also sends the same data back in the clear, then the point for exploitation becomes two-fold. As to how much risk is exposed due to the roundtrip of the data is unclear to me.

If we go by industry standard, I have seen more instances where password is not sent back to the page than ones that do. Google Account, Sony Playstation Network, Apple iTunes and Michael's GitHub example all abide by this standard.

@Allen: Thanks for your thoughts (and for adding even more examples).

Sony Playstation Network

Well, it's not the best example of security these days ;)

Well, it's not the best example of security these days ;)

I specifically chose this as an example because they've recently changed their security policy due to the attack.

@nickdunn: Do you still think that postback values for password fields should be included as an option? Most users won't understand the security implications, so I would rather keep it as it is now.

I do. I consider the security to be relatively minimal given the type of sites we're dealing with. If you're dealing with very sensitive personal data that would be incriminating or useful to hackers if stolen, then by all means take security as strongly as you like (e.g. Github stores your credit card details). But for the size and type of sites we generally create, registrations to relatively small member sites, I'm inclined to not worry and get on with it.

If I want to run an HTTP sniffer on my local network, I can already hijack cookies for things like Facebook, Gmail and so on (there are widely-available OS X apps and browser plugins to do this). So even if the user is signed in, I can still hack their account (by session hijacking). If the password is sent in plain text from the form in the first place, I don't see it as any more secure if you decide not to send it back in the response... it's already travelled across the network in plain text. Using SSL solves both problems (the password sent as plain text, and session hijacking) I believe.

I would personally be happy to ignore the edge case of someone walking away from their computer mid-form with the password saved in the HTML source. In this instance, a minor security blip is outweighed by the broken user experience. But that's just my bias.

I tend to get annoyed at sites that make me re-enter my password if the error wasn't on that field. It's even worse if I forget/don't notice that the password has been cleared, and instead fix the field that has the error (because it'll have error styling/something to alert me to the fact) then submit the form only to have it fail again because the password fields are now empty.

In my mind it creates a 'What? They were fine a minute ago, what's wrong with them now?'. I think at the very least it should be an option, and I would tend to have them 'still filled in' as the default.

I implemented a configuration setting to use password postbacks. However, the default is false. (I don't want to be blamed!) But it is very easy to change it, because you find it on top of the example configuration files:

<!--
    If the 'use-password-postback' value is true, any POST password value
    will be sent back as input field value. If form submission fails for
    any reason, this behaviour is more convenient for the user.
    However, sending the password value in the page source means a
    slight security issue, so it should not be used when security has
    the highest priority!
-->
<security>
    <use-password-postback>false</use-password-postback>
</security>

The "invalid" field rendering has not been reverted to the old version (nor is it depending on this config setting), because I realized that it always makes sense to render both fields (i.e. the password field and the confirmation field) as invalid.

Please test it and tell my if you find any glitches. I hope that everybody is fine now.

If nobody finds any issues in the next 12 hours, I will release this as version 1.0. I am a bit late already (since Members has been released).

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details