Order of authentication plugins

[MrDog]

Our login authorisation requires not only that the username/password are correct but also that the member's subscription has not expired - even if it has their record remains in the database. So I need a way in authentication to check this extra detail. In the past I have done this by patching the Joomla authentication module, but this is obviously not ideal.
So I have written a custom module to do this, using https://docs.joomla.org/J4.x:Creating_a ... for_Joomla as a guideline. The problem I am getting in that the standard Joomla plugin seems to be executed first and as it reports a success my code is not executed. If there any way of ensuring that my code is run instead of the standard Joomla plugin?

[sozzled]

There's another way.

The first hurdle people have to overcome is to be able to remember and properly enter their username and password. That's usually not difficult. The username/password method employs the standard J! authentication plugin. Other people have their rights assigned by a system administrator and access their work environment's resources using LDAP. Some people don't need a username at all and they login with a piece of hardware physically connected to their device. There are authentication plugins written for those situations. There are even authentication plugins designed so that, if you're logged into Google you'll be automatically logged into someone's J! website, too.

That's the purpose of authentication plugins: to employ different mechanisms that allow people to "login" to a website. It's after someone logs in that access is granted or denied to the resources accessible via that website.

So, the second hurdle in order to access certain "restricted" information is to have the information accessible to a logged-in user. You can restrict information based on a user's usergroup.

Let's say you have a usergroup called Subscribed-Users; Subscribed-Users would be a child of the Registered usergroup. When a user logs in they are no longer a Guest; they are a Registered User. If you want certain information further restricted to Subscribed-Users, the logged-in user would have to be a member of that group.

The technical term is "access control lists" [ACLs]; ACLs have been a feature of J! since J! 1.6.

Does it matter if a person is not a currently "subscribed" user just to be able to login to a website? Why get yourself tangled in a mess adding further barriers to people logging in? I would counsel against putting obstacles in the way of logging in but, instead, place barriers on accessing certain content that is reserved for the elite. That's the way that nearly all websites (including this forum, for example) work.

There’s nothing wrong with approaching things your way—I wouldn’t know how to achieve it—but I have to say that it’s a novel/unconventional approach. I don’t operate my websites that way and I submit most people don’t.

[toivo]

@MrDog, go to System - Manage - Plugins, click Filter Options, then Select Type and select 'authentication'. Click the Ordering icon in the Table heading to make it the active ordering item and drag the authentication plugins into the correct order, from top to bottom. That is the order the authentication plugins will be triggered.

The order can be verified from the column 'ordering' of the _extensions table. Run the following SQL query in phpMyAdmin or a similar MySQL client in the cPanel or a similar page, provided by your host. Use your own database name and table prefix.

Code: Select all

SELECT name, enabled, ordering FROM j4test.hddq8_extensions
WHERE folder = 'authentication'
ORDER BY 'ordering'

[Per Yngve Berg]

The ordering will not work here, because all plugins will be triggered and when at least one return success, the user will be logged in. You can disable the plugins that are not used. If the Joomla Plugin is used for some users, alter the Joomla Password. Then the password will not match and the Joomla Plugin will not return success, but the other Plugin will and login the user.

[MrDog]

Thanks toivo and Per - I have changed the ordering and yes if my plugin rejects the login then the Joomla one may accept it - I will try disabling the Joomla one later today

[sozzled]

Per is right; order is not really relevant. You can have more than one authentication plugin enabled and, in the event that one of them fails the system falls back to the next plugin in the "order" that you've defined (and the next and so on) until one of them succeeds. If no plugin succeeds then the login attempt is rejected. The "order" simply means that it may take longer or shorter for J! to authenticate or reject the login attempt.

If you have no authentication plugins enabled, no-one can login to the website, frontend or backend (including the system administrator).

I ask again, what does it matter if a login attempt is successful and, after logging in, the user cannot access things they're not entitle to access? It's a bit like giving someone the key to the front door of the house and, after they enter the house, they find that all the other doors are locked and they don't have the right keys to enter the rooms.

So, too, it is with using access control lists (see my previous post): after someone has logged into the website, the user's account is checked against their permissions to access the site content. That's the way most websites work: you login (or you don't) and you then see which "doors" are unlocked after that. It's "out-of-the-box".

[MrDog]

The only issue I have with that approach sozzled is that "someone" has to change the user's group once their membership has expired if I understand you correctly. Since the membership is maintained by an external body (who then give as the membership details to import) it either means they have to do this or I have to write some code for the import process to change members' groups. So either way more code to be developed.
I can also see that someone whose membership has expired will log in and then complain that they can't access the members-only content - and then they will complain to me. Whereas if I change the login authentication I can tell them when they try to login that their membership has expired.

[sozzled]

I see your point. Let’s set aside the hypothetical, that people will complain if/when (or maybe) they can’t access content they feel “entitled” to. That’s not the issue. The issue is about how to maintain/synchronise/co-ordinate with an external regulatory agency that tracks subscriptions. But, as you say, after someone has logged in you can provide information about a user’s current subscription status.

You’re right that you need something to synchronise something involving an external agency’s list of subscribers (presumably you’d have a mechanism to link their current list into your database), even allowing for timing fluctuations between your website and their list, it’s an issue. Does the external agency provide an API that allows verification of a user’s subscription status? Again, making the assumption that the user records in your website marry with the external agency’s list of users somehow.

Again, setting aside how to automagically assign users to user groups dependant on a subscription status (and there are ways to achieve that) my point relates to how you organise the web content inside your website. Using ACLs you have the means, out-of-the-box, to categorise your site content and restrict it how you like.

It’s a tough one. I’ll have to leave it in your capable hands. I’m only saying that your approach—verifying a user’s access rights before they can login to a website—appears to me to be an unconventional approach.

The JED has extensions for managing subscriptions: when users “subscribe” they’re automatically assigned to usergroups and unassigned from them when their subscription expires. So, indeed, it’s possible. In fact, that’s how I operate one of my websites (just saying).

Returning to your original question, though: the order of authentication plugins is not relevant.

[ceford]

Rather than a module, I think you need a plugin that responds to the onAfterLogin event. You can use it to take any necessary action such as posting a message and forcing logout.

[Per Yngve Berg]

Rather than a module, I think you need a plugin that responds to the onAfterLogin event. You can use it to take any necessary action such as posting a message and forcing logout.

That can be done in the Authentication Plugin. When the Plugin returns a System Message, it will be shown to the user at a failed login attempt. use a message such as "Subscription is expired".