I have a webMethods MWS server, when I am logging in with sysadmin user the header and footer tab is not showing up.
Error page looks like this -
While the correct page looks like this from another MWS server -
Can someone help me how to fix this error?
The sysadmin shell is called 'Power Drill Shell'. It's not supposed to editable.
Maybe your Shell Rule 'Sys Admin' has been edited. The rule should be:
(("Admin Role" matches user.groupMembershipDNs) or ("Admin Role" matches user.roleMembershipDNs))
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!'')}"/>
Gmail strips the lengthy password reset link and leads to a 404 page. Here is the mail receiving.
Data Team,
A request to reset the password for your account has been made at Test site
You may now log in by clicking this link or copying and pasting it to your
browser:
https://www.testsite.com.au/user/reset/22712/14926662...
[1]
This link can only be used once to log in and will lead you to a page where you can set your password. It expires after one day and nothing will happen if it's not used.
-- Testsite Australia team
[1] https://www.testsite.com.au/user/reset/22712/1492666251/YEBUB5BS_d6dTPkMHGoV4U3FYxwqtt0xsreHjp1FUCI
I am using drupal 7 and the mail is configured from backend admin/config/people/accounts as
[user:name],
A request to reset the password for your account has been made at
[site:name].
You may now log in by clicking this link or copying and pasting it to your
browser:
[user:one-time-login-url]
This link can only be used once to log in and will lead you to a page where you can set your password. It expires after one day and nothing will happen if it's not used.
-- [site:name] team
Anybody please get me a solution for this
Thanks
In your content format settings configuration increase maximum link length at admin/config/content/formats/plain_text set it as 999 as example.
My scenario:
I navigate to a login page.
I put in a known username with a bad password.
ZAP picks this up no issue.
I select the POST to the login page.
I find the lines that contain the Username and password. The password:
ctl00%24ContentPlaceHolder1%24cpLoginAspx%24ctl00%24LoginControl1%24LTLogin%24Password=12345&
I highlight the 12345 and right click to select Fuzz.
I had put in a custom list with the correct password for the test account and I select that.
When I do, it works its way through the list as I expected. Changing the 12345 to the various options in the list.
But, when it gets to the word I KNOW is the correct password. It does nothing different to alert me that it was correct. The password in this case was Password5. I expected that it would reflect or something showing it was directed to a new page. But, that happens for 'password' which is not correct for the test user.
I see this in the Fuzzer tab:
OK, I think the first point you're raising is that ZAP doesnt pick up that you've tried an invalid password. That is not a security risk - you supplied a bad password, the app didnt let you in. Everything's working as it should.
ZAP will only alert you of vulnerabilities via the active or passive scanners.
The fuzzer is for manual testing. If we work out a way to automate the detection of a vulnerability then we put that in the active or passive scanners :)
So you have to interpret the fuzzer results rather than expect ZAP to do that for you.
In any case, successfully logging in is not a vulnerability (in ZAPs terms).
What the fuzzer will tell you is if the string you supplied was included in the response (which is useful when looking for XSSs), the response code, the time taken and the response length.
When logging in I'd expect that the response length would be significantly different, so one option would be to look for a response with a length significantly different to the others.
However the easiest option is probably to search the fuzz results.
To do this go to the Search tab, select 'Fuzz Results' in the pull down and either search for a string that you know will be shown when you successfully log in, or do in inverse search for a string that you know will be shown when you fail to login.
Does that help?
Note that we do have a load of info on the ZAP wiki, including videos, FAQs and much more: http://code.google.com/p/zaproxy/wiki/Introduction
BTW we do have a ZAP user group which is intended for exactly these sort of questions: http://groups.google.com/group/zaproxy-users
You can also access it via the ZAP 'Online / ZAP User Group' menu item.
I try to keep an eye on forums, but there are so many that some questions are bound to slip through.
If anyone can suggest how I can convince people to use the ZAP user group (which all the ZAP developers subscribe to) instead of general purpose forums like this (which is very useful for other questions) then I'd be very grateful :)
Simon (ZAP Project Lead)
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).