Is there a bug with respect to Keycloak v12.0.4 ?
It is hanging on 'Account Console loading ...'.
HTTP sequence on clicking 'Impersonate' on all realms below. NB: https://example.com/authjs/keycloak.js is a 404 NOT FOUND.
POST https://example.com/auth/admin/realms/master/users/3467c293-741d-4345-8e06-a2a17ea71458/impersonation HTTP/1.1
GET https://example.com/auth/realms/master/account HTTP/1.1
GET https://example.com/auth/realms/master/account/ HTTP/1.1
GET https://example.com/authjs/keycloak.js HTTP/1.1
GET https://example.com/auth/resources/d5e5y/account/keycloak.v2/welcome-page-scripts.js HTTP/1.1
Yes, you are right this is a bug that according to the Keycloak mailing list is currently being tracked by the following stories:
authjs/keycloak.js 404 NOT FOUND related stories;
Infinite loop logging as an user or impersonating an user as admin.
The authjs/keycloak.js 404 NOT FOUND error on 12.0.x is related to this bug https://issues.redhat.com/browse/KEYCLOAK-16709?jql=text%20~%20%22%2Fauthjs%2Fkeycloak.js%22%20ORDER%20BY%20lastViewed%20DESC - you just need a leading / on KEYCLOAK_FRONTEND_URL and it fixes it.
Related
Clio API v4 returns ForbiddenError for every request.
For example this request works without problem:
GET /api/v2/users/who_am_i HTTP/1.1
Host: app.clio.com
Authorization: Bearer ***
And this request doesn't work:
GET /api/v4/users/who_am_i HTTP/1.1
Host: app.clio.com
Authorization: Bearer ***
This is the error returned with status 403:
{"error":{"type":"ForbiddenError","message":"User is forbidden from taking that action"}}
The same happens with any other request.
I was having the exact same problem. Here's a response from Clio, which resolved my issue.
We have recently made a change that requires all Bulk Action requests include bearer tokens in order to be successful. If you are making requests without including bearer tokens, they will fail.
Hope this helps.
I've found the solution.
The problem happened because the Bearer token has been received for application registered with APIv2 and/or in wrong domain (Europe instead of USA).
That means when I approved user I approved it against wrong application.
wget hangs there while it accesses the following website. But when I use a browser to access it, it will be redirected to https://nyulangone.org. Does anybody know why wget can not get redirected in this case? Thanks.
$ wget http://nyumc.org
--2018-02-20 20:27:05-- http://nyumc.org/
Resolving nyumc.org (nyumc.org)... 216.165.125.106
Connecting to nyumc.org (nyumc.org)|216.165.125.106|:80...
When I used wget on the site you mentioned, this is what I get:
--2018-02-21 21:16:38-- http://www.nyumc.org/
Resolving www.nyumc.org (www.nyumc.org)... 216.165.125.112
Connecting to www.nyumc.org (www.nyumc.org)|216.165.125.112|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 179 [text/html]
Saving to: ‘index.html’
index.html 100%[==================================>] 179 --.-KB/s in 0s
2018-02-21 21:16:38 (8.16 MB/s) - ‘index.html’ saved [179/179]
In the index.html file, which bears the logo of NYU Langone Medical Center, it says: "The following URL has been rejected for security concerns. If you believe you have received this message in error, please summit an incident with our helpdesk at 212-263-6868..." So, it may not redirect because the website can detect that you are a bot and not a browser. You could attempt to change the user agent string and other HTTP headers to avoid detection, but I'm not sure why you wouldn't just turn wget on https://nyulangone.org. Judging from information on archive.org, nyumc.org has been redirecting to other sites for at least the last 5 years. It was redirecting to http://www.med.nyu.edu until 2016, at which point it started redirecting to https://www.nyulangone.org.
I hope that helps.
First of all, great work. I donated because this could really save me lots of headaches. New to oauth2 and authentication in general. I signed up and registered # https://play.authlib.org/, added newapp. When I tried to authorize with the following uri:
https://play.authlib.org/oauth2/authorize?response_type=code&client_id=FhHzedZ9kdtQeTQRCwTgZELPdnHCEfEo7K0771U9XircD9Hh&state=e3dC66BGid2z0IwBinMgLKJ92IiD1r
it failed with:
{
"error": "insecure_transport",
"error_description": "OAuth 2 MUST utilize https."
}
Am I miss something?
There is nothing wrong with your code. The server itself has a bug (just fixed).
The playground is powered by Authlib v0.5 now.
You need to learn how to send requests for client_credentials:
https://www.rfc-editor.org/rfc/rfc6749#section-4.4.2
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
I just installed OpenAM 13.0.0, created an hosted IDP, and registered a remote SP.
Within the remote SP (a product called Questetra), I configured the entityID, login URL, logout URL, and certificate using values found in the XML at http://idp:8080/openam/saml2/jsp/exportmetadata.jsp?entityid=http://idp:8080/openam&realm=/
Problem: OpenAM says 500 Internal Server Error at the step where the browser loads the successURL.
Any idea what is happening?
Any tips on how to debug? There is nothing special in the Tomcat and OpenAM logs.
Shortened Wireshark trace
HTTP/1.1 200 OK
[...]
{"successURL":"/SSORedirect/metaAlias/idp?ReqID=a41de50e29c99ff3422f82b7g660ch6&index=null&acsURL=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2Fsaml%2FSSO%2Falias%2Fbpm&spEntityID=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2F&binding=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Abindings%3AHTTP-POST"}
GET /openam/SSORedirect/metaAlias/idp?ReqID=a41de50e29c99ff3422f82b7g660ch6&index=null&acsURL=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2Fsaml%2FSSO%2Falias%2Fbpm&spEntityID=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2F&binding=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Abindings%3AHTTP-POST HTTP/1.1
[...]
HTTP/1.1 500 Internal Server Error
[...]
<html>[...]HTTP Status 500 - Unable to do Single Sign On or Federation[...]</html>
Full trace at https://gist.github.com/nicolas-raoul/5ff26f37a95bc8088c6af7fe6ea5e468
Tomcat 7.0.72, Ubuntu 2016.04.1 LTS, Firefox 50.1.0
I solved this same error by taking the Certificate value directly from the metadata file exported from OpenAM and entering that directly again, to ensure that it was the exact same.
I'll start with the log that I am receiving below:
Dec.15.11.56-Rf: Incoming Request URL: /
Dec.15.11.56-Rf: SECURE GET Path: / From: mlocal.cldeals.com Rewritten: www.cldeals.com
Dec.15.11.56-Rf: Received 302 Found [text/html; charset=UTF-8] response for /
Dec.15.11.56-Rf: Sending 302 text/html; charset=UTF-8 response for /
Dec.15.11.56-Rf: Stats. Total: 0.52088702, Upstream: 0.48212701, Processing: 0.00105600, ProcessingOther: 0.04037500
Basically, when I go to mlocal.cldeals.com, it loads fine. If I click on another page, say mlocal.cldeals.com/products, that loads fine as well. The issue seems to be when I go to the account page and try to switch back to the homepage, maybe some type of security issue? When I try to switch back to mlocal.cldeals.com, the home page, it boots me off and sends me to www.cldeals.com. Is there something I can add to force this from not happening? Additionally, is this just a local server issue that would go away when I launch it on Moovweb's server? Any help is greatly appreciated.
Thank you.
It looks like the backend response to https://www.cldeals.com is a 302 to http://www.cldeals.com:80/. Not sure why that is the case (see note below *)
curl -v -o /dev/null https://www.cldeals.com
This response contains a hardcoded Location header and your project is passing along the response as is, which is why you are being booted off your local server.
Because the Location header value has a port specified, you'll need to modify your config.json to include this line in the mapping:
{
"host_map": [
"$.cldeals.com => www.cldeals.com",
"$.cldeals.com => www.cldeals.com:80"
]
}
This way, the SDK knows to rewrite that specific host:port value... (By default all HTTP requests go through port 80, so that information isn't really necessary)
*This is might be bug in the backend implementation because once you log in, you should be in HTTPS mode until you log out. (I can see some pages with personal information being transmitted over plain HTTP)