Automatic Drupal Registration Part II

DrTribos used Ask the Experts™
This continues from here:

Basic scenario is that I have some VBA code from which I would like to be able to direct users to a closed forum.  If the user is not registered on the forum then I would like to automate the process.

MlandaT provided the solution I asked for and Ray Paseur provided the warning that I needed...  thanks to both.

In reality, the exact circumstances are slightly more complicated than the original question alluded to.

The VBA code is subject to registration checks, which is done online using SOAP / POST etc..  The website that hosts the forum is NOT related to the website that checks registration.  

My current plan of attack is:
  • VBA sends request to a page on my Forum with: userName, PassWord, & registration details in the URL...   (the VBA has ready access to this information)
  • based on the registration details, the page that the VBA lands on sends a soap request to the registration website and waits for a response
  • If the soap response indicates the user is currently registered then login may proceed
  • If the current user does NOT have a valid login then a new account is created automatically as per MlandaT
  • If the current user already has a valid login then they are logged in

Does this alleviate all the security concerns? Is there a better way?

Many thanks,
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2004

>>> VBA sends request to a page on my Forum with: userName, PassWord, & registration details
>>> in the URL...   (the VBA has ready access to this information)

This is a bad idea.  Your application should interact with the web site using POST over an SSL connection.  It should wait to receive the registration details (existing or new), then forward the user accordingly.

Given your plan of attack, it does not seem you took Ray's warning to heart..  or at least didn't take it very seriously.  You need to be aware that:

1) Even in an SSL connection, the initial request is necessarily visible in plain text.  Putting any kind of security information in it is quite literally the same as taping the key to your front door to your mailbox.

2) Per Ray's post in the reference question, GET requests should not have the power to affect account status.  All it takes is one bot army operator to discover your application and you will have more bogus spam accounts than you can manage.  

3) Auto-creating accounts removes the personal responsibility users have for their own security, and places it squarely in your lap.  I understand the need to automate, and so does the industry.  That's why we have OAuth and other SSO resources.  Learn them, and more importantly, learn to use them appropriately.


It's not that I didn't take Rays post seriously, I simply have no experience and didn't understand it all... I tried reading the links and more widely but there's a LOT of jargon and assumed knowledge.

Although I should have, perhaps been more clear.... I think you make excellent points...

VBA sends information (username, password, and registration): this information is sent to a 3rd website the information is not related to the forum.  If the information is valid then an account would be created.

Ok fine, I get it now that I should use encryption... however, at a pinch could I MD5 hash & salt the credentials so that at least they are not passed plain text.

What are the implications for the communication between the 2 websites?  Who can eaves drop on that - as far as I can tell that is done without the knowledge of anyone except site A and site B?

Can you please provide an example of what this would look like
It should wait to receive the registration details (existing or new), then forward the user accordingly.

The reason I want to use this approach and not SSO etc. is that most of my users won't have a SSO account / won't want to use their personal SSO for a work related activity...   perhaps you can help me find the middle ground?!

Thanks for your comments, I really didn't understand what was meant by: "GET requests should not have the power to affect account status"  now I realise that because I use a the results of a GET request I am effectively giving GET the power....  I see that now :-/  

But, that said, with extra validation on the server side, salted MD5 credentials between VBA & Formum, validation of credentials between Forum and SiteB... would that appease?


note on the above, re passing creds... I didn't mean MD5... its early am here... I meant to obfuscate them so they look like MD5 etc... I think you know what I mean.  

other note.  if a user is not registered then the VBA code will have nothing to send to siteA, it won't even know the format of the credentials (e.g. aplha, numeric, special chars, length etc.)
OWASP: Forgery and Phishing

Learn the techniques to avoid forgery and phishing attacks and the types of attacks an application or network may face.

Top Expert 2004
Sorry, did not mean to sound disparaging..

First thing, read up on the basics of how OAuth works - this is pretty much what you're trying to implement, but in a private system.  In this case, your user is the user, your website is the consumer, and the forum is the service provider.  Also, you have a slight twist in that the initial request (step 2 in the article) is enough to generate a new user, if one does not exist.  

In basic steps, you have:
1) a page on the site where the user requests access to the forum
2) a handler on the site for (1) that can generate the initial call to the forum
  - after step 3 returns success, this same handler should forward the user to the (4)
3) a service endpoint on the forum that can validate/create the user and return an access token
4) a page on the forum to receive the incoming user and validate the access token
  - for new users, this page should also make the user aware of any credentials they need

In step 2, your site should send the forum the credentials to use, as well as any relevant information for creating an account.  For an existing user, this is just verification.  For new users, this should prompt user creation.  To be clear, all of this information exchange should be done over SSL connections, using curl or similar technology.  Any information you pass should be in the POST data; do not use GET methods for these service calls.  

>>> What are the implications for the communication between the 2 websites?  
>>> Who can eaves drop on that - as far as I can tell that is done without the
>>> knowledge of anyone except site A and site B?

There was a recent case in which it was discovered that a significant portion of domestic network traffic was being routed globally before being forwarded to its intended destination.  No one really knows why, but popular thought leans towards either espionage or criminals gathering PII.  The point here is you never really know who is listening unless you control every point through which your data flows.  That makes it very important to always use encryption on anything considered PII or sensitive information.

I would take a slightly different tack than you - I believe the user should create the forum account themselves and be able to link them to the site account.  But, while I'm not a fan of your desire to automate account creation, you know your needs best.  I tend to be overly paranoid (is there such a thing?  :P) regarding security issues, so take it for its worth.


Thanks for all this info.  I'll have some time this week to get into it a bit more.
Top Expert 2004

#41741711 provides an outline for resolving this issue.


Sorry this slipped off my Radar.  EE is broken, there were no reminders to attend to my question - not in my inbox and not in spam.   Also I might add that I completely agree with the rejection for the delete request...  HOW Steve Binks comments and effort be put at risk of deletion is beyond me.  EE needs to take a good hard look at the SO model.

Steve - many thanks for your insights.


Wow. Really?

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial