How would I allow a simple PHP site, which already has a user db, to let Drupal handle the logging in of users? I guess I could use services (but I would need help on this) or alternatively is there some way that users are passed to the Drupal login form to log in, but the simple external PHP site knows, through some kind of cookie arrangement, that the user is logged in?
The main priorities are that the user should only have to log in once for both sites, and the existing users on the external site can be maintained and transitioned smoothly. I want Drupal as the main user db because it's more secure and I think it's easier to have the external authenticate off Drupal rather than the other way around.
Any thoughts?
Bootstrapping Drupal is one way to do this. See : http://drupal.org/node/710560
It does have the overhead of loading other Drupal processes that you may not need, but at least it will give you the ability to add drupal's permissions system into your own app. I found that having the talker .PHP file in the druapl root to be the easiest way of working things; as you see from the above link, the working directories can be problematic.
There are few ways you can do that
Use drupal as OpenId Provider
User services module to expose the login service and call it in your php application. This module has good documentation.
I hope this helps.
Related
I have enabled Keycloak authentication in a website built with Drupal. As soon as I launch the website I want to redirect to Keycloak's login page if the user is not signed in.
Is there any way to achieve this as soon as I open the website
I tried making the default front page of Drupal website as localhost:8080 (which is where Keycloak's login page is present) but was unable to do it.
If you are experienced with writing custom modules, you can write your own implementation of event subscriber. Here is a good example of it:
https://drupal.stackexchange.com/a/223109/5644
If not, then I recommend the module https://www.drupal.org/project/redirect - I am not 100 per cent sure if it lets you to specify redirect only for anonymous but it is definitely worth trying.
I am assuming that the integration with the Keycloak service is working and out of scope of this question.
We are currently trying to use Concrete5 to create an internal Intranet for the company I work for (this is a web-based server). What we would like to do is allow our employees to sign in using their Gmail and be able to see their personal calendars amongst other things on sign in.
I would like the employees to just sign in once, get automatically asked for granting permissions during the login, and then be taken to the home page.
I'm having trouble figure out how to modify Concrete5's built-in Google login to request these scopes. I am pretty bare-bones in my PHP knowledge and no amount of Google searching has really answered my question specifically for modifying the authentication for Concrete5.
So to sum up my question:
How would someone go about modifying Concrete5's Google authentication to request additional permissions? We are using 5.8.3 and are always updating as necessary, so modifying the core is not really an option to prevent overwrites in the future.
The best way to do that would be to copy the core Google login system to create a new one. You could call it Google Custom or anything you want. You could include it in the folder application/authentication or in a package, with the appropriate modifications.
But to be honest, if you're bare-bones in your PHP knowledge, it all might be a bit too difficult to achieve
I am building a web consisting of MediaWiki and phpBB as its subcomponents. Also WordPress may be added in future. My current problem is to choose a single unified authentication method (not to force users to have a special MediaWiki account, a special phpBB account, etc.).
Which approach would you recommend me? The basic limitation is that it is a simple LAMP server (no LDAP database). Possibilities I know about:
Use a decentralized protocol such as OpenID, OAuth 2.0, etc. I would prefer this approach. However, OpenID is not supported by Google any more so OAuth 2.0 would be probably more appropriate.
Use DB of users from phpBB and install some plugin to other subcomponents (MediaWiki extension for phpBB auth.)
Use DB of users from MediaWiki and install some plugin to phpBB.
Use some specialized web application for user credentials management and install plugins both to MediaWiki and phpBB.
I think the main point you already understand: You need one of your new platforms to be the central user store. The problem you know have to find out:
What platform has the plugins to interact with each other? It's possible, that you find plugins, that only works "in one direction", and for mediawiki itself you will find a log of outdated extensions, that maybe won't work anymore with the latest mediawiki versions and updates.
The other point is, that you should think about WordPress now, too. After you selected one central user store you mostly can't change it with a lot of work, so I would check for an integration of WordPress now, too.
Looking at that and a short search i wouldn't prefer MediaWiki to be the central user storage, and i'm not sure, if phpBB is the best solution, too :/
I think one of the best would be to use LDAP, extensions and plugins seems to be supported and working for the latest versions of each software. You yould have a central user store, which could be easily integrated in other applications, too. What is the reason you can't use it, an LAMP stack could handle this, too?
The second solution i would consider to choose is to use Google's user store and access it vi OAuth 2.0. MediaWiki, phpBB and WordPress supports this with plugins and/or extensions.
At the end of the day a login is a login is a login. All the custom fields specific to individual applications can be properly bridged with plug-ins. Make the app that will require the most babysitting your main database and thus login system. In many cases it's the forum, but that really varies by site.
I would caution that many new forum admins eventually want to upgrade from phpBB to something that's more powerful and modern. I was one of those admins. Yes, phpBB is as good as an open-source forum gets, but it just doesn't compete with the commercial forum apps. So keep that in mind if you make phpBB your main database.
I have both Wordpress and Drupal installed on two domains. I want the users that register via Wordpress to be stored in Drupal's user table. Also, any login attempts should be checked against Drupal's database.
I don't have a lot of experience with either (though I'm fairly confident in my PHP skills). I am not looking for a way to mirror the users, but to actually tell Wordpress to use Drupal's database.
I think I have to rewrite the login and register methods on Wordpress. Am I wrong? And what's the best way to do this? (what files do I need to go into)?
You wouldn't want to tell Wordpress to use Drupal's entire database as it'll just create a lot more headaches. You're better off loading something like Drupal's boostrap and attempting to call the registration functionality, this again would cause more issues.
Is there a particular reason preventing you from using one system? Migration plugins/modules exist for both CMS'.
I'm sure others have come across the same issues.
http://wordpress.org/extend/plugins/external-database-authentication/
Wordpress and Drupal SSO/Single Sign On
How to register a user to Drupal 6.x without using the API?
I'm looking into building database driven websites based on opensource platforms in a sandbox area rather than having them accessible via the final URL until clients have paid up.
Is anyone aware of any problems this may cause with paths or functionality, or, know of any good articles on the subject?
many thanks
Shaun
There is no bad effect on functionality just because it is in sandbox. Generally, Joomla is almost location independent (untill and unless you are driving multiple websites from same joomla installation)
For security purpose secure the URL via .htaccess file (if more security required then setup a cron to update password every X hours, and email new details to user)
I would suggest having a cut-down, less privileged or demo account for signup users that can still enjoy the overall experience of your site without the full functionality of your killer-webapp services. "Restricting" them in a Sandbox area that is not even the actual site would not be as appealing and convincing as it could be for them to go from "freemium to premium" customers.
I develop all joomla sites on a local server and then upload to the production server once approved. In Joomla, when I upload the files to the production server, I usually need to change the mysql server as well and it can all be changed from the configuration.php file