Has anyone upgraded from v3 to v4?

There is a major security issue with v3 (passwords stored in plain text) and I'd like to upgrade to v4 ASAP (assuming it's more secure), but it seems like the bridge between the two versions isn't officially ready yet.

Has anyone actually tried to upgrade, and been successful?

I am in the process of getting everything prepared and, if all goes ok, will make the change over next weekend which is a holiday period in the UK.

From what I understand only problem updating is what payment system plugins you are needing. I use WorldPay which seems to be ok.

Hi AdamCapriola.

Storing passwords in plain text is certainly not the best practice but it's not a "major security issue" unless there is another security issue which allows people to get direct access to your server or database, in which case plain text passwords are the least of your worries. I wouldn't rush into anything just because of the plain text password issue.

What I would suggest is setting up a subdomain on your server like new.mydomain.com and creating a .htaccess file in the root folder for the subdomain to limit access to only your own IP address. Copy your existing database into a new database for this "new" subdomain and install aMember ( your aMember license permits this ) and point it to your new database. Test your upgrade process and payments etc until you are happy and then you can either move the contents of this "new" subdomain back into your main web folder or of you know what you are doing with Apache then you can change your Apache Virtual Host settings to treat the "new" subdomain as your document root. Remember, if you are testing payments that you also need to permit access to the IP range that your payment service provider will be using. Check with your payment provider to see what IP range their payment callbacks will be coming from.

As part of my day job I write the software for a very high volume website and I maintain the server infrastructure for a very high volume, top grossing iPhone app and I recommend this process for anyone who has to carry out updates and testing prior to deploying any upgrades or changes to a live website with minimal downtime. Creating a real working environment where you can test everything in a controlled fashion which is as close to the real web environment is very important. All of your testing should be done in this "staging" environment prior to rolling out to your live site.

And if you use the process I described then you could avoid any downtime or just have minimal downtime during your change-over.

Here is an example of the .htaccess file you should use to restrict access to specific IP's. Place the IP of where you are connecting from in place of 1.2.3.4 in the example below.

Create a file called .htaccess in the folder for your "new" subdomain and place this code inside it.

Code:

Options +FollowSymLinks
RewriteEngine on
#
# Redirect all except developer IP address to alternate domain
RewriteCond %{REMOTE_ADDR} !^1\.2\.3\.4$
RewriteRule .* http://www.yourdomain.com/ [R=302,L]

aMember 4 is very much a beta product.

It isn't as customizable as aMember3 and doesn't have all the plugins that aMember 3 has.

Unless your site has been hacked and users have been compromised I would not upgrade.

All I really want to address is the security issue brought up by Adam.

I can't say that I have upgraded from v3 to v4 as I've been happily using aMember quite well since 2007.

I've processed over 100,000 subscription payments, have over 56,000 users across multiple sites and processed over $2,000,000 in business (one of the sites being over 65% of that total).

If I would sniffed a mild hint of a security issue (which I have never had one with that many users in 5 years) -- I would upgrade pronto. But given how large one of the aMember installs is and so well established with thousands of active subscriptions, Alex advises against an upgrade.

Nonetheless -- I don't believe there is any security risk unless your web hosting account or server were compromised. As so long as you have a strong password like the ones generated by Cpanel (i.e., 2fG!d2j+3a3j) and make sure your file permissions are properly set and not "777" -- then you should be fine.

Should the screenshot attached to my post not put your mind at ease, I don't think anything will.

We're actually doing a clean install of version 4 and then migrating data from our version 3 database. It's been a long drawn out process and I did have to hire someone with deep Amember experience to assist. That said, the first test migration went well and we're hoping to migrate to our production AM 4.x site within 2 weeks.

I'm not sure if I would AM 4 is still in beta and I'm certainly pleased with the new version. However, the documentation even for the new version continues to be woefully inadequate. With today's ability to easily screen capture, not sure why more time hasn't been invested in adequate documentation and how-to articles.

It isn't just difficult to use for tinkering programmers but there's all sorts of faulty logic and programming.

You cannot create a product id like you create in a shopping cart. It is an autoincrementing number field in the database. If you want to change that then it messes up the entire system.

ANY good shopping product allows you to change the product id. For example we have people that see they purchased "product id 5" but they get confused and think they got charged 5 times. That means more support headaches for us because this functionality that is common to most shopping applications is missing from aMember4.

Then let's talk about modifying the signup forms and signup process. There's a lot of advanced stuff that can be done to signup forms to make them more effective. However we are finding aMember 4's new form builder to be very clunky and limiting.

So if you're selling your first product online and are going to take all the defaults aMember gives you then using 4 may be the right way to go. If however you want to do custom stuff it is not the right solution.

Well, my site actually was hacked recently (last week) due to an exploit in the amProtect plugin. I do not know what the hacker's motive was, but my web host said aMember v3 violates a cardinal rule of security programming, which is to NOT store passwords in plaintext.

Is it aMember's fault that amProtect has a bug in it? No, but it is still negligent to store passwords in plaintext, especially with the state of hacking on the internet right now. aMember even has control of amProtect and sent me a recent copy about a month ago when I was checking to make sure I had the most recent version.

So there is a possibility that hackers from Ukraine stole thousands of user's e-mails and passwords from my site. I don't have any way to tell if they actually did that, but there is a small chance and it makes me feel terrible.

Anyway, I went ahead and upgraded to v4 for the better security. Most things seem to be working smoothly, but some users are having issues with aMember not logging them into WordPress and vBulletin. I also am going to have to redo all my sign/login/sales pages, which I'm not quite sure how to do yet.

I use PayPal as my payment processor for recurring payments. I think that's the only payment system that is compatible with the upgrade at the moment.

Don't think you will find that statement is fully correct. What Alex has said, if you check back, is that PayPal is currently only recuring payments system that is fully compatable with the current upgrading script.

I know for a fact WorldPay seems to be fully compatable with version 4. I have spent quite a lot of time testing it and have yet to find a problem.

With all due respect I fail to see how you can claim aMember to be at fault for amProtect problems. It was originally written , and supplied, by kencinnus NOT aMember. If aMember supplied you with a copy of this script then no doubt they did so as a courtesy to you and maybe to help you out.

It would have been more informative, to others, to explain what the exploit was and also what type of server your site is hosted on. If it is a 'shared' hosting then this, in itself, could be classed as more of a risk than the actual fact of using plain language passwords.

aMember acquired all of Ken's plugins from what I understand, so they should be responsible for them. On March 15th I asked aMember support if I could get a copy of the latest versions of amProtect and aMail, and the response was "Yes we own these plugins now." (direct quote)

I e-mailed aMember about the exploit in amProtect, which my web host diagnosed + fixed, and aMember said they would stop distributing it. They also said they would contact Ken to inform all his lists of the exploit, but I don't think this was ever done, which is in my opinion negligent.

I use shared hosting, but the biggest issue my host said was the plain text passwords. They said that even they wouldn't run software like that, and recommended immediately removing it because of the risk. I didn't even realize the passwords were in plaintext until they told me about it.

I understand the argument "it's not aMember's fault if your site gets hacked, so plaintext passwords are a non-issue" but that's like Ford selling a car with no seat belts, and saying if you get in a crash and die, it's not their fault. It should be standard safety.

In your opinion on whose part?

If what you say is correct and aMember now own, or took over responsibility for these plugins, are you claiming they also aquired a list of people who purchased them? It could well be the case that aMember notified their original supplier and it would be him, who should have the relevant sales lists to notify his customers.

You say aMember is neglegent in storing plain language in view of the level of hacking NOW. The core of aMember 3 was written around 10 years ago. Remember aMember was designed to integrate with a number of third party scripts including a number of forums etc. and standardisation of password storage was not at the level it might be now.

Alex, and his team went with the idea of encoding passwords, in more than a single way to suit other third party scripts, with version 4 but to produce a piece of software such as aMember cannot be achieved overnight! This version has been some time in the making, as you will see if you care to look back in the forum.

As for your scenario re car crash. If you get into a car crash it can hardly be blamed on Ford, or any other car manufacturer. You get in a car crash - your, or other drivers, fault end of. Car manufacturers were forced into fitting seat belts because drivers simply couldn't be trusted to drive safely. They need wrapping in protective devices to minimise the injuries they received from their own incompetence!

Back to your own scenario. It would have been more benificial, rather than trying to aportion blame, that you posted up what your host discovered was the problem, and how they cured it.

Totally agree Alex

I forwarded all this information to the help desk on April 27th. It should be their responsibility to get the information out there; not me.

It's in the email invoice. This information is passed to authorize.net by amember. Then included in the authorize.net email invoices.

Again this is common functionality of most shopping software that is missing from aMember. For example have you ever had a client that has their own sku numbers or product numbers? Our client also wants to change the product id so when we generate sales reports for them the numbers match their internal numbers.

BASIC functionality that is missing in amember.