Currently, I have decided to use Drupal as the primary login area where users can do stuff. Problem is, I want to automatically allow for the logging in of users using their cpanel, whm or whmcs login details. Anyone?
I really don't suggest you to do this.
You will only introduce more risks to all your systems, even if Drupal is a very secure system.
There are sometimes authentication security issues, with cPanel drupal and whmcs. Now, imagine those security issues + the ones of drupal, + the ones on whmcs...
...with all these insecurity layers combined, it's a real security bomb, and not something that will help your customers that much you are going to create. ...plus your modules for this will probably experience someday security issues also.
I suggest to take a look at other web hosts : if they don't do this, and if even whmcs do not bridge with vbulletin on their own website, there is a reason for this! ;-)
There seems to be no module for this.
Also Drupal seems not to provide a direct way to connect 3rd party login systems.
Having a look at the LDAP integration (file ldapauth.module) in the package, you can use the hook hook_form_alter. The check whether the form is using user_login_authenticate_validate in the validate entry and replace it with their own authentication function.
Basically you can use the ldapauth.module file as a basis and start with the ldapauth_login_authenticate_validate function.
In this function you have to add code that uses $form_values['name']; and $form_values['pass'] and verify them against your cPanel database.
A completly different approach would be to write a cPanel module to create Drupal users and update the accounts. To get started you can have a look at writing cPanel modules.
Related
What is the best way to password-protect a folder on IIS with a single set of credentials to be shared by a group of users?
Our hosting service offers Plesk, which in turn offers a "password-protected directory" function, but some of our clients have HTTP authorization disabled, so they get an automatic 401.4 error with no prompt for credentials.
I've looked into Forms authentication but this seems cumbersome to set up for the numerous separate domains at issue.
The protected content is not super sensitive, we just don't want it easily accessible to the public. Many of our users do not use the site frequently and we don't want to implement individual credentialing for everyone (we do have that in place for more sensitive sections) just so they can view current project reports or meeting minutes.
On sites I don't control, but am just a user, that do the same things as mine, it is a big pain to have to look up a username and password twice per year just to view a meeting agenda (yes, browser could remember but they also have a 4-month expiration and lots of us are on different devices all the time).
Is Forms authentication the way to go? Took a several hours for me to get it set up and working, with all sorts of settings not well documented in a single place.
(I had previously asked about how to disable Basic Auth on the client side, was told more than once it's not possible - but it is, via client/browser registry keys)
Thanks.
It's perfectly fine to use forms authentication. All you need to do is navigate to the folder or file you want to protect, then go to Authorization Rules. Add a deny rule for anonymous users, when users who are not logged in try to click on any file in that folder, they will be redirected to your login page. You can find a lot of guides on forms authentication in Google, you can refer to the following:
https://learn.microsoft.com/zh-CN/troubleshoot/developer/webapps/aspnet/development/forms-based-authentication
https://learn.microsoft.com/en-us/iis/application-frameworks/building-and-running-aspnet-applications/how-to-take-advantage-of-the-iis-integrated-pipeline
I'm trying to find a solution to my problem, and I hope I can manage to explain it properly.
I have a VPS (Debian 11 - Apache2) with root access. I added (so far) the following domain and subdomains to my VPS:
mydomain.com
play.mydomain.com
read.mydomain.com
watch.mydomain.com
study.mydomain.com
And I will probably need to create more subdomains soon, but I need to solve this problem first.
We are just 15 people in my Team who need to access to this domains/webpages. As you surely know, subdomains are independent domains on a web server. How could I give access to these subdomains ONLY to my work team? I can't create login access because each subdomain is an independent (and always different) CMS, it would take very long to customise each one, same for every time I add a new subdomain. Is there any way to give access to specific people without any login screen? I don't know for example with a token, or configuring the web server, or having a common login page? I have no idea what could be the best solution since the authorization must be managed outside the websites themselves, so any suggestion would be very much appreciated.
Thank you very much for your help,
Elliot
Please don't hesitate to suggest any possible solution! Thank you!
We are trying to allow our business users to be able to verify a new site's production look and feel as well as to allow a select group of internal users to be able to view new sites that are authored and created in AEM.
One idea, is to set up a Launch Page that the general public would see, and for the pilot group, they would set a cookie in their browser to be able to see the pilot site.
We have looked into VHosts settings, but can't spot anything, and are thinking perhaps a conditional pass through rule based on the cookie in the header as being the easiest approach?
Any thoughts would be greatly appreciated.
Currently Azure Websites don't allow custom SSL certificates, but they have wildcard SSL enabled for the *.azurewebsites.net domain. I need a secure login form for my web app, but with no custom SSL, it appears that I'm SOL.
Is there any kind of workaround for this? Would it be possible somehow to have a login form at https://mydomain.azurewebsites.net that creates a forms authentication ticket that will then work at http://mydomain.com?
Couple of months ago I had exactly the same problem i.e. application was built on Azure Websites, had to run on custom domain other than *.azurewebsites.net and had to allow secure login process.
Workaround for that we used was to embed an iframe (using secure protocol and .azurewebsites.net domain name e.g. https://oursite.azurewebsites.net/login) into non-secure page on custom domain (e.g. http://mysite.com/login). And entire login process was performed in the iframe.
There is one thing which you should be aware of, namely, lots of customers checks whether the page where they provide their credentials was using secure connection or not. In our case, secure iframe in non-secure page was causing lots of customer complains. Workaround for that problem was to put a message confirming that the login process uses secure connection. The message made some improvements, however, still certain number of customers complains remained.
I hope that will help.
This isn't really an answer to your question, but Microsoft are very aware that custom mapped SSL to websites is one of the most requested features for Azure websites and they have said they are working on it.
Scott Hanselman himself confirms it here
In the meantime, Tom's answer is a perfectly valid workaround.
One thing I would be very wary of though is with something Tom brings up: the security warning that the browser will present. You'd be amazed how many people freak out when they see that message and don't go any further! We have a fairly active ecommerce site and there have been occasions where we have accidentally used a none secure image path on an SSL page and we have always received emails from customers asking if our site has been hacked or similar!
The disclaimer that Tom mentions is a good idea, but I think it will still put some people off.
I am working directly with the WAWS team right now to produce some public guidance for this. A GitHub repository with the requirements is currently being evaluated by the team (I sent it over to them literally 1 hour ago). Hopefully, the solution will be approved and made public within a few weeks.
I can say this - the workaround won't be fully supported or much custom guidance given on its usage aside from the repository and accompanying documentation. SSL is, literally, the #1 priority for the product, and hundreds of people are working insane hours to make it happen for everyone. This workaround should also be considered temporary, as you'll no longer need it once the full SSL functionality is launched.
I would like to make it possible to redirect users from a site to my Moodle installation, providing two encrypted parameters in the url. Based on these parameter, Moodle should authenticate the users and grant or refuse access.
Is anyone familiar with this, and can anyone point me in the right direction?
Should I build a new plug-in, modify index.php ? Both ?
Basically the php code to process the GET-parameters is ready, but I don't know how and where to insert it in the Moodle code.
Cheers for helping, much appreciated
Paul
This is a problem solved many times before. The best option for doing it securely is to use one of the existing auth plugins. If the sites are on the same server or you are happy to allow direct database access so that Moodle can read the password hashes from your other site's DB, then you can use db auth, which is simplest. Otherwise, you'll need some sort of cookie based one. I've used CAS authentication before, but shibboleth is also an option. This may seem like overkill, but really, it isn't. Just having auth tokens in the url leaves you open to brute force password-guessing attacks, so the challenge-response mechanism that these plugins provide is very important.