Automatic Drupal Registration Part II
This continues from here: https://www.experts-exchange.com/questions/28944519/Automatic-Drupal-Registration-and-Login-From-VBA-VB6-Net.html
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:
Does this alleviate all the security concerns? Is there a better way?
Many thanks,
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,
ASKER
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
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?
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?
ASKER
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.)
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.)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for all this info. I'll have some time this week to get into it a bit more.
#41741711 provides an outline for resolving this issue.
ASKER
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.
Steve - many thanks for your insights.
ASKER
Wow. Really?
>>> 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.