I'm sure my API keys are correct and my domain is checked.
I use 127.0.0.1 as a domain to develop every state of reCAPTCHA.
reCAPTCHA returns 0.9 and I set threshold = 0.99 to test the reCAPTCHA,
but it shows me every time this ERROR for site owner: Invalid key type.
It seems to be a problem with reCAPTCHA.js.
I have no idea.
I solved that. It is necessary to execute reCAPTCHA by the version 3 sitekey, and render reCAPTCHA by the version 2 sitekey.
Related
I'm trying to use keycloak with a react app, this is my current client configuration...I did this inside the master realm
this is my keycloak config
export const keycloakConfig = {
"realm": "master",
"auth-server-url": "http://localhost:8180/",
"ssl-required": "external",
"resource": "demo",
"public-client": true,
"confidential-port": 0,
"clientId" : "demo",
"url" : "http://localhost:8180/"
};
I based my code on this repo
now...I can login without problems in my app, and the displayed url is this
http://localhost:8180/realms/master/protocol/openid-connect/auth?client_id=demo&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2F&state=ba9daf04-ffdb-4ad3-b912-8be846f0684b&response_mode=fragment&response_type=code&scope=openid&nonce=558d71b7-2c66-44f8-9297-84694dc571a8
but when I try to logout I get a message
Invalid parameter: redirect_uri
the logout url is this
http://localhost:8180/realms/master/protocol/openid-connect/logout?redirect_uri=http%3A%2F%2Flocalhost%3A3000%2F
I'm not sure if my client config is correct because this has several missing parameters in almost all tutorials that I've found
Do you know what could be the problem here?
thank you guys
From the Release Notes:
OpenID Connect Logout
Previous versions of Keycloak had supported automatic logout of the
user and redirecting to the application by opening logout endpoint URL
such as
http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri.
While that implementation was easy to use, it had potentially negative
impact on performance and security. The new version has better support
for logout based on the OpenID Connect RP-Initiated Logout
specification. The parameter redirect_uri is no longer supported;
also, in the new version, the user needs to confirm the logout. It is
possible to omit the confirmation and do automatic redirect to the
application when you include parameter post_logout_redirect_uri
together with the parameter id_token_hint with the ID Token used for
login.
The existing deployments are affected in the following ways:
If your application directly uses links to logout endpoint with the redirect_uri parameter, you may be required to change this as
described above. Consider either removing the redirect_uri parameter
entirely or replacing it with the id_token_hint and
post_logout_redirect_uri parameters.
If you use java adapters and your application does logout by call httpServletRequest.logout(), you are not affected because this call
uses the backchannel variant of the logout endpoint and that one was
not changed.
If you use the latest javascript adapter, you are also not affected. However if your application uses an older version of the
JavaScript adapter, you are affected as this adapter uses the variant
of the logout endpoint with the deprecated redirect_uri parameter. In
this case, you may need to upgrade to the latest version of the
JavaScript adapter.
For the Node.js adapter, the same guideline applies as for the JavaScript adapter. You are encouraged to update to the latest version
as the older version of the adapter uses the deprecated redirect_uri
parameter. With the latest Node.js adapter, you are not affected as
long as you use the logout based on the /logout URL as described in
the documentation or in the Node.js adapter example. However, in the
case when your application directly uses the method
keycloak.logoutUrl, you can consider adding idTokenHint as the second
argument to this method. The possibility to add idTokenHint as second
argument was newly added in this version. The idTokenHint needs to be
a valid ID Token that was obtained during the login. Adding
idTokenHint is optional, but if you omit it, your users will need to
confirm the logout screen as described earlier. Also they will not be
redirected back to the application after logout.
There is a backwards compatibility option, which allows your
application to still use the old format of the redirect_uri parameter.
You can enable this parameter when you start the server by entering
the following command:
bin/kc.[sh|bat]
--spi-login-protocol-openid-connect-legacy-logout-redirect-uri=true start
With this configuration, you can still use the format with the
redirect_uri parameter. Note the confirmation screen will be needed if
the id_token_hint is omitted. Warning The backwards compatibility
switch will be removed in some future version - probably Keycloak 21.
You are encouraged to update your clients as soon as possible as
described above rather than rely on this switch.
I've got the same problem already for hours. The only way I found a workaround is manually sending the user to:
/realms//protocol/openid-connect/logout
I started using Keycloak 18.0.0 since a few days and I cannot find any other solution for this problem. I guess it's only happening to when using the newest version. Maybe we should read the documentation better.
For last Keycloack versions you have to redirect explicitly to
https://you server url/auth/realms/matrix/protocol/openid-connect/logout
This issue comes when the keycloak is upgraded to version 18. So we also need to upgrade Keycloak JS & keycloak-angular package.
https://www.npmjs.com/package/keycloak-js
https://www.npmjs.com/package/keycloak-angular
Rest everything will be similar
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.
I got a notification from Facebook saying that they will invalidate calls from URIs not listed in the Valid OAuth redirect URIs this coming March 2018 and I think they are requiring us to Enable Strict Mode for Redirect URIs. Link about this can be found here.
I have been using their PHP SDK with Strict Mode disabled for a year now without any problem however when I do enable strict mode and place there the redirect url which is: https://nino-dot-dynamic-osprey-93721.appspot.com/admin/fb-callback_admin.php - it returns an error as seen below each time I try to Login with Facebook:
Graph returned an error: Can't Load URL: The domain of this URL isn't included in the app's domains. To be able to load this URL, add all domains and subdomains of your app to the App Domains field in your app settings.
Note that I'm simply using FB's default PHP SDK Login code (https://developers.facebook.com/docs/php/howto/example_facebook_login) which have login.php and fb-callback.php links and I'm not using any custom OAuth workflows.
I noticed that the redirect URL generated contains the code and state parameters:
site.com/admin/fb-callback_admin.php?code=somecode&state=somestate
I think this is the reason why I'm getting the error because it only expects a redirect URL of https://nino-dot-dynamic-osprey-93721.appspot.com/admin/fb-callback_admin.php without any trailing parameters.
How do you guys think of getting around this issue of Enabling Strict Mode given that the response of the redirect URL through the below code:
$helper = $fb->getRedirectLoginHelper();
$permissions = ['email']; // Optional permissions
$loginUrl = $helper->getLoginUrl('https://nino-dot-dynamic-osprey-93721.appspot.com/admin/fb-callback_admin.php', $permissions);
echo htmlspecialchars($loginUrl);
is generated from FB's PHP SDK by default?
Change
$accessToken = $helper->getAccessToken()
to
$accessToken = $helper->getAccessToken('http://www.example.com/admin/fb-callback_admin.php');
I had the same issue and found this answer in this thread, which seems to resolve the problem for me:
Graph returned an error: Can't Load URL: The domain of this URL isn't included in the app's domains
Not sure why this works, though, but glad it did.
I was facing the same issue, Actually, this comes from the facebook graph sdk.
I got this information from here
Also, a quick and dirty change that seemed to fix this error for me
was adding 'code' to the list of params to remove in
FacebookRedirectLoginHelper
later facebook itself released the updated package which seems fixed the issue.
make sure you have the latest version of facebook-graph-sdk at the time of this answer, the version is 5.6.2
I am building an app with the use of ember-simple-auth.
So it looks very much like the library its doing is thing.
Here is what happens:
user tries to access /dashboard but is redirected to /
the route / contains the login form
the user logs in with valid credentials
Server responds: /token 200 0.252 ms - 52
But an error message is shown: Error: Assertion Failed: The route index was not found
user navigates to /dashboard and can now see the content, navigate around protected areas, and successfully log out.
My question is, how do I define /dashboard as the route instead of index? So that after successful login you are redirected to /dashboard
You can configure Ember Simple Auth's routeAfterAuthentication in the config, e.g.
ENV['ember-simple-auth'] = {
routeAfterAuthentication: 'dashboard'
}
4 years later...
On Ember Simple Auth Part, you can add routeAfterAuthentication and call it a day, because of ESA default to index.
If we dig deeper, as far as why ESA was and still defaults to the Index route, is that Ember always generates 2 routes for you:
one "" for ApplicationRoute
and "/" for IndexRoute,
You get these 2 routes for free.
I found 3.20 version doc's wording is verbose, so I'm pasting from 1.10 doc, but the idea remains the same
On that perspective, ESA uses IndexRoute as default is a safe bet.
when I use a proper SSL Certificate on my Web-Site I get bugs in joomla which don't appear if using an unknown certificate of http:
When logging in with wrong credentials, I get to the error page 500 instead of validation and instead of the message "Username or password are wrong ..." faded in.
When registering and the wrong text in ReCaptcha is tipped instead of validation the data in all the fields is deleted and no message about wrong captcha is faded in.
What am I doing wrong when using the proper SSL-Certificate?
Note to ReCaptcha:
In K2 I put the script source metioned here.
Putting
RewriteCond .*(/component/users/?view=login) off
at the end of my .htaccess didn't help.
Technical data, which may be relevant:
SSL-Certificate: GeoTrust RapidSSL
CMS: Joomla! 2.5.9 Stable
Login-Form: Standard-Module of Joomla
Register-Form: Authentication-Plugin of Joomla + K2 2.6.2
Thank you very much in advance.
I have solved the problem. It wasn't an SSL issue.
These paths in configuration.php were not correct at the root and I've overlooked it :(
public $log_path = '/SERVER_PATH/JOOMLA_INSTALLATION/logs';
public $tmp_path = '/SERVER_PATH/JOOMLA_INSTALLATION/tmp';
So when you log on with wrong credentials or type a wrong ReCaptcha text, joomla tries to create the directories mentioned above. If joomla fails to do it (and it was the case), instead of validation by login form and ReCaptcha you get the strange behavior, described in my previous post.
#Lodder: I'll update my K2 next time
#Jobin Jose: Yes, I activated SSL adminside.