I would to change the default login page (to /content/ethz_ch/Login)
I configured tha page by the Day CQ Login Selector Authentication Handler
In ./launchpad/config/com/day/cq/auth/impl/LoginSelectorHandler.config I see
auth.loginselector.defaultloginpage="/content/ethz_ch/Login"
as expected.
I then configured a test page (/content/ethz_ch/de/auth_test.html) with a closed user group and left the login page field blank.
When accessing the test page, instead on the newly defined login page I am redirected to
https://..../system/sling/cqform/defaultlogin.html?resource=%2Fcontent%2Fethz_ch%2Fde%2Fauth_test.html&$$login$$=%24%24login%24%24
Any idea on what I am doing wrong?
In the Day CQ Login Selector Authentication Handler there is a Path Info setting which restricts the possible login pages:
A list of request extensions indicating requests for which the Login Selector Authentication Handler may request credentials. Any request whose extension is not one the listed extensions will not cause the credentials to be requested. If this list is empty the default list of html and htm is used. Note that the list entries must not have leading dots. Requests without extension or requests with trailing slashes (/) are always handled by the Login Selector Authentication Handler regardless of this configuration.
Specifying the Default Login Page with the full URL (with extension) solved the problem:
/content/ethz_ch/login.html
Related
I'm currently troubleshooting a login issue for a deployed Moodle. Login page uses an alternate page which I have managed to identify. The alternate page considers everything except successful login as invalid or expired login or password.
Since some correct login and password are also getting the same issue.I am trying to restore the Moodle instance to use its default login page but did not find any $CFG->alternateloginurl configuration set in moodle.php. Kindly please provide any pointers you can think of on where to look next to restore the login page.
PS: I've also searched within the active theme, and there has not been any code changes. Uses a variant of Moove
Thank you
Rest assured that its a common issue
https://docs.moodle.org/401/en/Managing_authentication#Alternate_login_URL
There is an entry in the database
SELECT *
FROM mdl_config
WHERE name = 'alternateloginurl'
Note the value, just in case, then blank it out
UPDATE mdl_config
SET value = ''
WHERE name = 'alternateloginurl'
Then purge the cache to update Moodle
php admin/cli/purge_caches.php
When you do manage to log in, check which other authentication methods are active via
Site administration > Plugins > Authentication > Manage authentication
https://docs.moodle.org/401/en/Managing_authentication
The default methods are manual and email self registration
Although self registration is disabled by default in the settings on the same page (registerauth)
Once again I created my own authentication service. This is registered and is also called. After submitting the login form (EXT:felogin) you get back to the same page - but Felogin continues to show the login form. After a page reload, the logged-in state is recognized correctly and the status display is displayed.
The same form works correctly with a normal, local FE user.
When debugging authUser() correctly returns 200.
What could that be?
Besides returning 200 by authUser(), having a valid FE-User (at least with uid, pid, username, usergroup) is necessary. My FE-User was broken.
TYPO Documentation - Authentication services:
One important thing to know is that the TYPO3 CMS authentication process needs to have users inside database records (“fe_users” or “be_users”).
On my current project, I use wicket and Shiro for authentication and authorisation. The problem is that for pages with an error code 404 the session is lost. Only mounted pages i.e. pages with a fixed path (/home, /users...) get a session, so when I type server:port/giberish the session is lost and I see the login page in the header. It seems that this behaviour is implicit because I could not find anywhere configuration for this.
I have a ColdFusion enabled form (for validation) submitting to a separate page. When this form is submitted it is showing me a 404 on the action page, yet when I directly load the action url into the address bar it shows up (errors appear, but that's ok). This is by far one of the most odd issues I have encountered.
Form page: http://www.jefferson.edu/population_health/_archive/contact_me.cfm
Action page: http://www.jefferson.edu/population_health/_archive/contact_action.cfm
Even if I try passing the form variables via URL it gives me a 404.
My gut is that there is another service on that machine that is trying to take over the request whenever you submit data and binding it to another webserver...which, of course, it can't find the right page based on it's own webroot.
If you click http://www.jefferson.edu/population_health/_archive/contact_me.cfm, it loads fine and returns 200 header with IIS as the server, but if you click http://www.jefferson.edu/population_health/_archive/contact_me2.cfm it throws a 404, as expected, but it's properly handled with a custom 404 and the header response is still IIS. But if you click http://www.jefferson.edu/population_health/_archive/contact_me.cfm?foo=bar, it returns an ApacheSling default 404 and header information saying the server is "Day-Servlet-Engine/4.1.12".
Your page is posting to the page contact_action.cfm ... in your question you indicate that the proper page should be "mailaction.cfm".
If the action page is actually mailaction.cfm then you simply need to change the action attribute of your cfform.
In our app (service provider), there is a security filter to prevent viewing certain pages. For example a user can view a.xhtml but not b.xhtml. The user can login to view a.xhtml. And if he type in the URL to b.xhtml, the security filter will redirect himi to an error page.
Using josso, before login, user may type the url to b.xhtml and would be redirected to josso login page. After successful login, user will be redirected to the "back_to" page, which will be b.xhtml. In this case the security filter is not triggered, the use can see b.xhtml!
Refresh on b.xhtml then will trigger the filter and send user to error page, but too late.
We use josso 1.8.5 and tomcat 7.0.26.
Please any guru can help?
Thanks