tags:

views:

381

answers:

1

My client is insistent that there be a single page where both Joomla administrators and users can log in, as opposed to the default Joomla setup where these two groups log in in separate locations (/administrator for the admin). While the reasons for the client's insistence are besides the point, essentially it's a small group where only some users can do CMS type management of articles etc., but they don't want to have to go to separate pages, go figure.

Anyway, is there some sort of extension for this, or would I have to write an authentication plugin to handle? Could the controller for one type of login call the other login and pass through the same credentials, and if so how would that be put into code?

+1  A: 

Actually admin users + normal users can log in in the front end (the normal page). Admin users can edit articles their, whereas normal users can't.

All other things (like creating categories etc.) needs to be done in the backend (/administrator/). I suppose you want the following scenario:
1) You log in at your.site.com
2) you click at a link to your.site.com/administrator/
3) and without retyping the password you are logged in into back-end.

As far as I know, a such extension (authentification plugin) does not yet exist. But it should be feasible. At both locations (frontend and backend) the same plugin will be used. So for passing the information that a user is logged in, you could try:
- whether the $_SESSION is the same
- if not, set a cookie with an random id, store this id in the database (together with username), and ask for such a cookie when checking login.

I wouldn't modify the existing login plugin, instead, write a new one with only this alternative login method. All published Authentification Plugins are ORed, i.e. as long as one of them allow to log in, everything is ok.

Tutorial: http://docs.joomla.org/Tutorial:Creating_an_Authentication_Plugin_for_Joomla_1.5

giraff
Thanks; you describe the scenario correctly, and I'm going to try writing a plugin -- will approve answer when I get it working.
Dan U.
Will go ahead and accept since this looks like it would be the right approach. A co-worker was able to talk the client out of this requirement so it's not something I need to do, and hence can't confirm directly.
Dan U.
Well, actually, this is the best solutioin :-) Seriously, I had some scrupels on how to implement it without creating a security hole. But actually, I have these scrupels as soon as authentification / authorization is involved.
giraff