Symphony.

Updating from 1.0 to 1.1 I get the following:

MySQL Error (1091): Can't DROP 'value'; check that column/key exists in query "ALTER TABLE sym_entries_data_62 DROP INDEX value"

When updating from 1.0 to 1.1, have to remove current members section, then get success update. How can I keep current member section and update members extension? What is the right step?

1. Rename the old members section to old_members.
2. Create a page (type, xml) and output a ds of all the members to that page, use xsl:copy-of in xslt.
3. Create a new members section using the new fields.
4. XML Import the page and map the old fields to the new ones.

I think that should work.

@padexx Comment out these lines (for now, it's a bad oversight on my part) and then retry.

@wastemobile Why do you have to remove the current member section? You shouldn't have too, what error do you get otherwise?

@brendo Sorry, my wrong. I just got same message like @padexx, so I tried to disable member estension, got message "The field 'field.memberactivation.php', provided by the Extension 'Members', is currently in use. Please remove it from your sections prior to uninstalling or disabling."

So...

• Remove member section and update, work.
• Rename old member section like @designermonkey said, work.
• or just comment out those lines in extension.driver.php, work.

@wastemobile, @padexx I've pushed a fix to Github, would you be able to pull and test?

Installed without errors using the fixed version!

Glad to hear it! Hopefully @wastemobile has the same experience and then I'll package up the fix.

Thanks!

@brendo Just pull the fixed version and try it, works so well. Thanks a lot!!

Members updated to version 1.1.1 on 13th of August 2011

• Fix update script in 1.1
• Explicitly set the CHARSET to be UTF8 when creating new tables.

1.1.1 is a recommended update for all users as it fixes a problem with the 1.1 update script that may make your Members install not function correctly :)

Hello there!

Is there any guide on building discussion board on top of the Members extension?

There is a working Forum Ensemble, but it is using my much modified alpha version of the Members extension. So, I don't recommend using it. It will be soon replaced by the new Forum Ensemble, but there is no upgrade path between the two versions.

If you are interested, try out the Forum Ensemble beta.

(sorry: slightly off-topic)

@bauhause Have you made any progress with the Basecamp-like ensemble I remember you were developing some time ago? If so: does that already use the new Members?

I am currently using Basecamp but would love to be able to use something OS and Symphony-based :)

I have been planning a seriously high-security project that sadly has been re-scoped into Codeignitor, but raised a great question I think I will ask here anyway.

Is it possible to generate a unique hash to salt user passwords, that is unique to each user? Currently the Members Password field doesn't allow this, but I thought it may be a great addition to the field.

Any thoughts anyone?

Do you mean creating a hashed password which contains a random salt? I recently created a field called "Email Password" that does this – the email server in question (to be precise: the Dovecot daemon which handles email user login) can work with this type of hashes.

It's not complicated to handle these password hashes in PHP. I agree that random salt would be a nice addition to the Members Password field, but: Shouldn't we put emphasis on author passwords first? If I am not mistaken they are still stored as unsalted hashes, while Member passwords are salted.

Unfortunately changes to hashing mechnisms require all passwords to be reset in order to take effect...

The current method is to enter a 'salt' for the passwords, that stays the same for every member, but the security requirement of the project I'm planning requires a unique 'salt' for each user, which can be used as a unique identifier too.

I have done this in Codeigniter very easily, and was just wondering if it should be a feature of the Members extension, to either enter a global salt, or check a box to create a unique one for each member.

Re the authors passwords, I did not know that! Passwords should always be salted IMO, and I'm at a loss to hear they aren't!

Unique salts in the form of a SHA1 hash are the safest way, as then a salt change only affects the single author/developer/member in question.

Normally one does not use a complete SHA1 hash as salt (but just some bytes), because you have to store the salt appended to the password hash. (For other readers: You can recover the salt easily, that is no issue here. The goal of this technique is to hinder brute-force attacks with rainbow tables. You would need one rainbow table per salt.)

Just a quickie, how would one go about logging out a member? I can't figure it out at all.

i think you append ?member-action=logout to the url.

Could anybody please give me a sample of a new member registration form on the front end and the settings for the event in the backend?