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)
Related
I know there's an earlier question with this subject here, but the OP never reported if the one answer resolved the issue. And since
Internal Server Error
is about as user-unfriendly as you can get, I would love to change this to something that feels more like "a message" than "an anvil dropped on your foot".
I have found one other SO post that tangentially relates to this issue (about that disappearing "duplicate emails" switch), but the problem is indeed not about whether or not to allow duplicate emails (or how to revive hidden admin controls) but how a very ordinary issue is communicated to the user - well, like how Keycloak notifies the user when they try and register with an existing username.
We're currently using the Docker version of Keycloak 12.0.4 with some customisations (a custom BCrypt module, some logging changes) running in IBM Cloud, using a Postgresql DB. We also added a custom theme & internationalisation. The same error occurs also when using the default Keycloak theme, though.
Here are our Login settings:
It turned out to be a configuration issue, but so deeply hidden that even the Keycloak developer who looked into the ticket I created had glossed over it.
The perpetrator was in menu Configure > Authentication > tab: Flows > choose dropdown: Registration > Profile validation radio button [o REQUIRED | o DISABLED]
This was set to disabled, which in effect prevents the duplicate email check in the registration form that the Realm settings > tab: Login form suggest are active. But then, of course, the database won't like that, with above-mentioned result.
This combination of settings should at least issue a warning, of course. I hope this will be corrected.
In Keycloak, by default, users are able to change their first and last name in the account manager page. However, is it possible to disable this behavior?
Removing both fields in the theme results in those values not being sent and the form failing, and a hand-crafted POST request would defeat this method anyway.
I came across a similar problem and after reading this SO post, came to know that although you can disable/hide fields in ftl, you cannot disable form validation
For e.g I hid firstname field , but still cannot submit. Same was the result with disable as well:
I am not aware about disabling a particular field in some other way. However there is a workaround in which you can disable the entire account modification flow (Password can still be changed by Forgot Password option).
Bu default, account modification is enabled, but you can disable it for a particular realm by going to Realms -> Clients -> Account.
The result of this will be, the account page will be inaccessible:
You can remove the client role 'manage_account' for client 'account'.
In Keycloak, by default, users are able to change their first and last
name in the account manager page. Is it possible to disable this
behavior?
That can be done out-of-the-box (since Keycloak 14) by using the user profile functionality. First, the preview feature declarative-user-profile has to be enabled. For that start the server with:
--features=declarative-user-profile.
for the Quarkus version, or with
-Dkeycloak.profile.feature.declarative_user_profile=enabled
for the Wildfly version.
Bear in mind that:
Declarative User Profile is Technology Preview and is not fully
supported.
After starting the server with the aforementioned option, go to the Keycloak Admin Console and:
Go to the according Realm;
Go to the tab General;
Set User Profile enabled to ON
A new tab named User Profile (top right) will show up; click on it, and a set of configurable attributes will be shown.
Click on firstName, and then go to Permissions
In that section the permissions can be changed, accordingly. For example, if one sets Can user edit? to OFF, then when the user tries to change the firstName field in the account UI, that UI throws the following warning message:
The field First name is read only.
The same configuration can also be applied to the lastName attribute.
For the new Keycloak UI the workflow is exactly the same as the one I have just described. More information about the feature can be found in the official keycloak documentation (link)
You can use readonly property to disable email you can just change the following line:
<input type="text" class="form-control" id="email" name="email" readonly autofocus value="${(account.email!'')}"/>
Following is the code i'm using for prog login for my application.
UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken(userName, passWord);
token.setDetails(new WebAuthenticationDetails(request));
authentication = authenticationManager.authenticate(token);
LOGGER.debug("Logging in with [{}]"+ authentication.getPrincipal());
SecurityContextHolder.getContext().setAuthentication(authentication);
after this a model is returned (without changing URL, i can see usename n role here). on that view, there is a form. which submits to another link with role permission same as of current user.
but when user submits the form then spring redirects it to login page and invalidate the session.
I have checked and found that jsession is is appended with .undefined (mS5YoJL3YfznQNuItNUeiLd6.undefined) and i suspect that this must be the problem.
I've checked it, and undefined was coming because of Jboss AS 7.1 and this whole issue was coming because I was not creating session while auto login. I have changed the code and its running perfectly. Thanks for your response. –
I need some help troubleshooting.
I've just upgraded my 1.3 site to 2.0 (with the intent of going on to 2.1). I get the actual page running, content is read from DB etc, but I cannot log in to the admin panel!
Just to make sure I didn't forget the password I did
<?php echo sha1('password' . 'salt'); ?>
Taking the salt from the DB, and the output is the same as is stored in the DB. But still I cannot log in. The log in prompt just reloads, no error message or anything. Any ideas?
I've also tried clearing cache/sessions/etc, and even a different browser to no affect.
Crossposted from the PyroCMS forum: https://www.pyrocms.com/forums/topics/view/19323
OK, since there doesn't seem to be any good suggestions found either here or on the PyroCMS forums and my site is very small content wise I decided to just wipe everything and do a clean install of the latest build instead.
Not a very good solution for future reference, but it will have to do.
From my checklist (it's been a while since I had this happen to me):
If you didn't get an incorrect password error, it may well be you were just being redirected back to the login page before the details were even checked. You can run into issues with enabling the 'Remove index.php from URL' in .htaccess - in /system/cms/config/config.php try changing
$config['index_page'] = 'index.php';
to $config['index_page'] = '';
or (as you've hinted):
clear the contents of default_ci_sessions table
clear the cookies for the domain (a quicker way is to just open a new Google Incognito window which won't have any cookies).
Also - you can initiate a password reset for the admin password using the ordinary user login form if you or someone else does ever forget it (don't though).
I have rather special need in login to vBulletin not from forum directly. I looked through topics by searching "vbulletin login", but found nothing.
So here's the structure.
domain.com - main site, access is
restricted by ip range
domain.com/forum/ - vB with cookie's
host set to .domain.com, of course
it's also restricted by ip
extra.domain.com - secondary site
which is available to almost anyone
('almost' includes users of vB
created manually via ACP)
As for now users already authenticated at domain.com/forum/ are recognized both at domain.com and at extra.domain.com.
So the problem is to login from extra.domain.com to domain.com/forum/
However i can't just post entered usernames and passwords to forum because of ip restriction. As I get it, there should be some wrapper, which will do all the login procedure via cURL or somehow, get all the cookies and then return them to user.
First of all, please tell me if I'm on a right way in my thoughts? Also are there any other ways to complete task without having to spend hours with HTTP sniffer? I mean are there any SOAP plugins for vB auth from trusted domains? Forum version is 4.0.8
Does the code on the secondary site have access to the vBulletin code & database? If so, you can handle vBulletin logins in PHP like so:
chdir('/directory/where/vbulletin/is');
require_once('global.php');
require_once(DIR . '/includes/functions_login.php');
// Check for too many login attempts
$strikes = verify_strike_status($username, TRUE);
if ($strikes === FALSE || $strikes >= 5) {
// TODO: Your error handling here
}
// Attempt authentication
if (!verify_authentication($username, $password, '', '', TRUE, TRUE)) {
exec_strike_user($username);
// TODO: Handle bad username & password here
}
// Clear records of previous bad logins
exec_unstrike_user($username);
// Create a new session
process_new_login('', TRUE, '');
The code above should work with vBulletin 3.8.x, but from what I remember of 4.x it shouldn't take much tweaking to make it work with 4.0.8.
Set the 5th parameter to verify_authentication to false if you wish to make the login non-persistent (like not checking "Remember Me" on login).