URL for Front-end External Login menu item is losing HTTPS prefix when being passed to CAS server
eddiekonczal opened this issue · comments
We are experiencing this problem with External Login package 3.1.2.2 and Authentication - External Login Plugin version 3.1.2.2:
The front-end External Login menu item, if clicked on from the front-end of the Joomla! website itself, works with CAS.
However, if the URL for the front-end External Login menu item is entered directly into a browser window, the following error is received:
"The service you were attempting to authenticate to is not allowed to use CAS."
It seems that the menu item is losing its https prefix upon being redirected to the CAS server.
Can you post an example here?
Here is an example:
If you visit:
https://sasundergrad.rutgers.edu/
you should see that the URL for the login link at the bottom of the page is:
https://sasundergrad.rutgers.edu/front-end-login
When our users click that link, they can login to CAS. But if they enter that URL directly into a browser, they get redirected to:
https://cas.rutgers.edu/login?service=http%3A%2F%2Fsasundergrad.rutgers.edu%2Ffront-end-login
and the error appears:
"The service you were attempting to authenticate to is not allowed to use CAS."
If I manually change the above URL to
https://cas.rutgers.edu/login?service=https%3A%2F%2Fsasundergrad.rutgers.edu%2Ffront-end-login
(adding the s to https after "https://cas.rutgers.edu/login?service=")
CAS then works.
Please need somme help for using the component.
It since to be working only with id=casuser. Do i need to do something for synchronize joomla user on cas server ?
We found that when you add a Joomla! User, you then need to authorize the user via "Components > External Login > Users"
yes that's what I did. but I would like to know if it is obligatory to have a ldap server on the server case to recover the joomla account
What we have done is disable LDAP authentication, but keep Joomla! authentication active in case the CAS service ever goes offline.
In which place ?
In Joomla! back-end, "Components > Plugins"
do your users connect with the joomla connection module or do they use the external login module which redirects the page to case / login?
On the back-end, the External Login module.
On the front-end, a menu item that links to External Login.
so they are automatically redirected to the apereo login page. they must identify with their id. This means that the CAS server retrieves these idenfiants at a given moment. So the CAS server is connected to an LDAP base that needs to be powered, right?
my CAS login page. only works with the generic idenfiant of apereo (casuser)
On the back-end, the External Login module.
On the front-end, a menu item that links to External Login.
why do you have a login module in a back-end ? & how it is possible ?
so if you are using External login user can not connect in joomla if cas server down ?
So the CAS server is connected to an LDAP base that needs to be powered, right?
I am note sure about this. It is my understanding that CAS is an alternative to LDAP.
my CAS login page. only works with the generic idenfiant of apereo (casuser)
I'm not familiar with apereo
why do you have a login module in a back-end ? & how it is possible ?
So you can log onto the back end using CAS. You just need to configure the module and assign it to the "Login" administrator module position of the administrator template
so if you are using External login user can not connect in joomla if cas server down ?
No, we do not disable the standard Joomla! login for the back end, Both are available.
apparently it would not be necessary to install an LDAP server. But I have to configure my CAS server to communicate with my joomla mysql database which is on another server. Can you confirm it to me or do you know someone could guide me?
Sorry, I have not actually configured a CAS server. The purpose of the External Login is to allow Joomla! to communicate with CAS, not the other way around.
Hi, I am just checking to see if any progress is being made towards troubleshooting the issue reported in this issue.
This issue seems to have been resolved by Joomla! 3.9.12.