VBulletin + Amember: Users - Please share Info!

Over one year ago, I posted my experiences with an attempted integration of these two programs. My post is here: http://www.amember.com/forum/showthread.php?t=2864

Although everything was installed, we never took the program live and have never used amember. We are talking with alex now about changes and updates and hope that we will give it another chance.

HOWEVER: a few versions have passed since my original post and I'm looking for anyone who is using VB and AM together.

I would specifically like to know if the issues pointed out in my post have been resolved to the point that AM can handle *ALL* new members and log-ins ... OR ... is log-in still split .... paid via amember and free via vb?

(IE: "All your free users should register in vBulletin, and once user will decide to upgrade membership, he should go to aMember")

Thank you for sharing your experiences!

This is what we wanted to do a year ago but was not able. Here is what you told us at the time. If this is not correct now, then something MUST have changed:


Well, I found the problem. VB3 use additional salt to crypt password, so standart import will not work, because salt is different for all users. Also First way (we was talking about) will not work too.

So you should do this using Second way. All your free users should register in vBulletin, and once user will decide to upgrade membership, he should go to aMember signup page and order membership using the same username/password/email as he use in vBulletin, so aMember will upgrade group.


[size=+1]
ARE YOU SAYING that it can now be done completely in AMEMBER?
[/size]

I guess I just don't understand your response.

Are you saying: If you add amember to an existing VBulletin installation, you can NOT transfer the usernames and passwords into amember? All existing members MUST create new accounts in AMEMBER?

And to avoid duplication, you must delete all existing members in Vbulletin so that they can sign up with their same username in AMEMBER.

Is that what you are telling me?

Here's a Solution...

Let's try this question a different way...

Alex, is there perhaps a MANUAL for Amember that can be reviewed by prospective buyers? There obviously should be. I suspect the issue here is that Alex and VIP are simply talking past one another. I've been a software pro for nearly 40 years now and a systems analyst and designer too. In my experience, there is almost no software problem that is unsolvable if we're willing to think about it creatively enough... It's only a question of how hard it is to do and getting an understanding of the actual problem that needs to be solved is ALWAYS the hardest part.

What I think I hear Alex saying is that there are two ways for users to register in a Vb - Amember site. The first way is to register through vB... but that only works for "free" members and isn't really necessary at all because AMember actually can handle both registrations. Furthermore, I gather that if a user registers in Vb and later decides to purchase a membership he must then register a second time and unfortunately he has the option in doing so to select a different username and/or password for Amember than he chose for vB. I think Alex is also telling us that he doesn't really think that's a good IDEA, but it's certainly possible for the user to do that... unless we can come up with a way to prevent it!

Am I correct, Alex?

I gather Alex is also telling us that all registrations CAN be handled through Amember IF the webmaster is willing to set up a paid membership that costs "$0". Am I correct on THAT, Alex? The obvious trouble with THIS approach is that AMember is essentially working blind and is ignorant of the user's vB password. At the moment, that means they could choose a different username and password for Amember than they chose for vB and then end up being cvery confused about which username and password they should use in a given situation. To solve that Alex suggests either assigning every user would a new password or forcing them to provide a new one when they sign up in AMember. I THINK Alex is telling us that Amember doesn't currently have a better solution for that problem.

Again, am I correct, Alex?

If that's true, I respectfully suggest Amember can solve that dilemma by doing the following:

First, when the user tries to register through Amember, the program could look for the standard vB cookie on the user's machine. I'm certain that the cookie MUST contain either the user-id or a record identifier (key) that can be used to look up the user-id. Otherwise, vB wouldn't know who the user was either! I'm betting that cookie contains the username. THat's what would make sense... even though using the record-id would be a more secure way of handling it. So, knowing that cookie exists, it seems to me AMember could grab that username and use it as the one they require the user to use and then not allow them to change usernames. That solves the first problem for everyone EXCEPT the rare user who has actually logged out of vBulletin before signing up in Amember. Sadly, there is no solution for fools and idiots. Our world is filled with them. If you don't believe me, take a good look at the U.S. President!

Next, Amember could ask the user for their vBulletin password. The password they provide could then be encoded using the same MD5 encoding technique that vB uses (including the randomizing "salt" value which is permanently stored in the user's vB database record) and that encrypted password could then be compared to the encrypted password stored in the user's vB member record. If it matches, the user will be allowed to go on and make a payment. If it does NOT match the user would be told the password is incorrect and be invited to either re-enter the password or (if he has forgotten his vB password) he could be sent to vB's assign new password process and if the proper return info is passed to vB he would automatically be returned to Amember's sign-up screen when he's done and can asked to enter his password again. Then the username cookie check and password comparison process could be repeated. Using this technique, Amember's programmers don't have to try to untangle the gordian knot of how to decode that MD5 and salt encrypted password. but they can still force the user give them their vB password anyway -- even without knowing it!

There may be a flaw in this logic somewhere, but if there is, I don't see it. Hell, I was even able to make more than one PERL product handle the MD5 Encryption of a user entered password and send that encrypted password to vB to check it against its user database. And I'm certainly not a PERL programming Guru at all! In fact, I'm basically an advanced hacker in both PHP and PERL who has learned just enough to eventually figure out such things. By doing that, I was able to integrate several unrelated apps written by PHP and Perl programmers spread across the world from England to Indonesia and make them all share a single vB member database. So if I can do it, I'm sure the experts at CGI-Central can do it without much grief at all.

Using this technique, Amember could FORCE the user to choose the same password in AMember that he chose in vBulletin without knowing what that password was until he finally provides a username and password that passes the encrypted password comparison test. This solution prevents the highly undesirable situation of a user having two different usernames and passwords on the same site and allows Amember to make the user choose the same username and password for products without Amember needing to do the impossible task of trying to decrypt that MD5-and-salt encoded password.

It does, however raise two other issues. First Amember would need to provide a patch to the vB select new password process that would call an Amember program and pass it the username and password. This way, AMember would be able to get and record all password changes for Amember users who are already in their database. Second, Amember would need to provide a patch to the vBulletin member DELETE process to ensure that any members who are deleted from vBulletin's database by the webmaster are also removed from AMember's database as well... or at least the webmaster could be ASKED if he wants to remove the user from both databases! I had to do this in my vB-Indexu integration. So, I KNOW this can come up.

So, the big question is, what have I missed here, Alex? And can you tell us how soon your programmers will be finished with this change?

Now, Alex, I have three other questions. In response to an earlier question from me you said changing the Amember code wasn't something I could do. Were you implying the source code for this product is not provided to users (or is somehow encrypted)? Or were you merely assuming in saying that that most users wouldn't dare to do so and wouldn't know where to begin? For obvious reasons I refuse to buy any program I cannot change. I've been doing this FAR too long not to realize that no programmer thinks of everything (as this thread clearly shows) and I always assume the programer may not have solved some problem I will encounter.

So my first question is: Is source code provided with Amember or not?

Next, I gather Amember is written in Perl. Is that correct? If so, are you considering rewriting it in PHP or is Perl the the only language you guys use?

Thanks very much. I hope this suggested solution CAN eventually be coded (and soon). VIP and I are certainly not the only ones who know they need a better member management solution than we now have and Amember is the best product of its kind that I've found. Frankly, I'd love to be able to buy this product. From what I can tell, I think it would solve several very annoying problems for me at once.

Thanks Alex for your support. It's truly excellent. I only wish every software vendor had someone like you around to answer such questions!

Now go take your whip and beat those programmers for a while and tell them we need this solution YESTERDAY!

Best Professional Regards,
Thomas Platt
a.k.a. WebSissy

I do want to make it clear that I am not complaining. Amember is an incredible package. I bought it specifically for use with vb, and in that sense, I believe it has INTEGRATION weaknesses that should be disclosed.

Here is a summary of the situation of integrating amember and vbulletin:

1. NEW VB SYSTEM - NO MEMBERS: Amember can handle all aspects of registration and membership management if you are starting with a fresh, new board and you begin with amember. You bypass ALL vbulletin log-in and registration prompts, allowing amember to handle it all (registrations, subscriptions, payments and log-in access).

2. OLD VB SYSTEM - WITH MEMBERS - AMEMBER HANDLES ALL REGISTRATION: You can import the usernames into amember, which will force new passwords to be generated for all accounts and mailed to your users. They can then enter amember and change their password to the one they originally wanted. All new members would register through amember; and all existing members would enter through amember - bypassing all registration services of vb. This can be a one-time inconvenience to your members, but it allows you to use amember for ALL registration/membership aspects.

3. OLD SYSTEM - WITH MEMBERS - DUAL ACCESS SYSTEM: Members register with vbulletin and obtain "free" access or whatever access the webmaster chooses to manually set for them. When a member wants to pay, he must click a link to amember; create an account with new password; pay through amember -- and enter vbulletin through amember. When his membership expires, he can enter through vbulletin's log-in system rather than amember. This is even more of an inconvenience to users; and a headache to webmasters with complaints and confusion.


To the best of my knowledge and understanding, these are currently the only methods possible of integrating amember and vb's registration/membership system

I personally never thought you were complaining, VIP. I only heard you trying to clarify the current situation with Alex.

As I understood what Alex was saying, it sounds to me like you've got the present Amember capabilities sorted out pretty well.

Does he, Alex?

Of the three options you described, it seems to me the second one would probably be the best one to choose as things sit now unless the guys at Amember can implement the solution I suggested in my earlier post. As far as importing existing members goes, it seems like Amember could eliminate the password assign logic and the issues it causes with users and just import the vB members directly into the Amember database with their vB-encrypted passwords. If Amember manages to duplicate VB's encoding logic, they wouldn't NEED to require a password change at all. I've done that in PERL myself. So I know it can be done. They can just ask the user for his vB username and password and then encode the password to check it against the vB password they imported.

Have VIP and I missed something, Alex, or are we all "on the same page" now?

Thanks!
Tom Platt
WebSissy

Alex, I wasn't suggesting changing the password encryption scheme at all. I only suggested duplicating it. By doing that, you would be able to take the password provided by the Amember user and encrypt it the same way vB does then compare the encrypted password to the encrypted password vB has stored for the user. This would let Amember verify the password without knowing what the original password was. As I said, vB stores the salt value used to encrypt the password in its database along with the encrypted password and the encryption technique it uses is quite standard. I was even able to replicate the encyption results in the CGI code of ImageFolio (my image gallery tool). So if I can do it then surely you can too. That technique would as least avoid the need to force the user to change passwords.

As you've pointed out decryption is very difficult. SO don't WORRY about decryption. Just encrypt instead and see if it matches!

It's just a suggestion. Do with it what you will.

Again, thanks for the reply.

Best Professional Regards,
Websissy

Friend Alex, I'm afraid I must disagree with you on this one.

In a world where there are tens of thousands of sites using vB and hundreds (if not thousands) of webmasters who would like a better payment and membership management solution than vBulletin is ever likely to provide, I think your policy is a serious mistake. Nevertheless, it is your policy. So I am forced accept it.

I think it represents a short-sighted view. Frankly, I'd buy Amember in a minute if I didn't have to deal with the confusion and headaches and support problems that changing my 4,000 user's passwords is guaranteed to create. It took over a year for me to build up that user list. I'm not prepared to have 4,000 user pissed off at me. Would you be if you were in my position?

On this one, I wish you'd change your mind. If you keep your patches to vB to a minimum (The two small changes I described for vBulletin were very minimal. They took the experienced PHP programer I hired to write them less than half a day to develop and test.), I don't think it would be a big problem for you to be able to support vB's future upgrades. Other vendors do it. And from what I've seen, they seem happy they did.

Best Professional Regards,
WebSissy

I see. I was confused because I thought the "CGI Central" board was actually AMember's board. Obviously I was mistaken about that. Sorry.

And you're welcome. Even when I disagree with you, I still think your support is exceptional!

Thanks again.

Best Professional Regards,
WebSissy

Alex,

I think you are misunderstanding the way the salt value is used by vBulletin. Yes, the value is randomly selected when the user signs up. But AFTER that, vB stores the salt value as a permanent part of the user's member record so that it can be used again later to encrypt the password the user enters when they login and compare it to the encrypted password vBulletin has stored.

The only time the stored-in-the-database salt value ever changes for a user is if they change their password through vBulletin. So, if you had the salt value and asked the user to provide their vB password you could easily encrypt the provided password and compare it to the one stored in vB's database. If it matches, the user can login. If it does not match, he cannot login. It's that simple.

The reason the password is encrypted is not to keep the honest webmaster from logging in as that user on his own site if he NEEDS to. It's to prevent unscrupulous webmasters who KNOW users tend to use the same password everywhere from stealing a user's password and then using it in other places to pretend to be that user.

Incidentally, in cases where I need to be able to login as a user in an effort to see a problem they are having WITHOUT knowing their password, I've been work around the password encryption by doing the following:

First, I use MySQL to display and record the user's encrypted password and salt value. Next I change the encypted password and salt value stored in the member's record to the one that's stored in MY member record. Now, I am able to log in as that user without knowing their password. When I'm done with whatever I must do, as my final step I remove my encrypted password and salt value from the user's member record and restore the original ones. The user never knows I logged in as them even though I have NO idea what their password is and don't really care.

I hope this is helpful to you, Alex.

Best Professional Regards,
WebSissy

Tom, unless I am mistaken -- this is similar in concept to the "check" you were talking about. I'm rephrasing what I understand to be the procedure that Alex explained (so that I can make sure it is clear to me):

It appears from Alex' statement, that the encrypted password is checked against the VB password. If it doesn't match, he can't continue with that username. In this case, he likely didn't come from inside a secured vb area.

On the other hand, if he already logged into (a secured area of) vb, then clicked onto a link to AMEMBER, the user and encrypted pass are passed to Amember. The user then enters his password again so that amember gets it -- and it must match what was passed from vb to amember.

SO to my list of possible solutions perhaps we add: If there was a way to allow the user to log-in to VB; then re-direct them into amember so that they can convert their user/pass to amember, that would be ideal.

TO ALEX:

I would like to share my opinions as to *WHY* I want to import all members into amember.

1. I specifically bought amember for vb because vb doesn't handle ccbill. As everyone knows, vb already has a membership module built in with some credit card processors installed.

2. I wanted to "replace" the vb log-in and registration system with amember, so that there was only *ONE* place to sign-up and log-in.

Under the current system, free users are in vb's system directly. To log in, they go to a vb log-in page. That is simple.

If they want to pay, we penalize them by making them go to another system and create a new account. And we make them always log-in through that system rather than through vb. When their payment term is finished, they must stop using the amember log-in and begin using the vb log-in section.

The goal is to ELIMINATE confusion and duplication. There is NO REASON to have two methods of registration and log-in. The more confusing it is to users, the less likely we are to have long-standing paying users.

Thanks for reading and replying to this thread. It has been quite interesting for those of us who are working with vb.

No, Alex... importing passwords from vBulletin is NOT impossible. What's impossible is being able to DECRYPT the encrypted password to figure out what the original password was. But if the user provides the same password and the value used to "salt" the original password is stored in the database (as it is in vBulletin's database), you can EASILY encrypt the password provided and compare it to the encrypted value of the original password stored in vBulletin's database. If the two encrypted passwords match, the user can be allowed to enter. If they do not match, you can deny him entry.

It's important to realize the encrypted password value does not need even be UNIQUE. There might well be a thousand dictionary words that would produce the same encrypted value if the same salt value was used on them. The goal behind encryption is to prevent unscrupulous souls from easily stealing the original passwords and using them for devious purposes.

I posted a way to work around this in another posting here. I won't repeat it now.

Again, Alex, I hope this explanation is helpful to you!

Best Professional Regards,
WebSissy