Details
-
Type:
extRequest
-
Status: Closed
-
Priority:
Blocker
-
Resolution: Done
-
Fix Version/s: 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:
-
HD-Chapter:Security
-
HD-Enabler:KeyRock
Description
It seems that the POI client cannot ask the KeyRock server about user, e.g. the name, making it difficult to show the name or other information of the logged-in user as customary. This seems to be due to missing CORS (cross-origin resource sharing) support in the /user resource.
More information: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Code snippet from the CORS support of the POI server for reference (PHP):
... if ($_SERVER['REQUEST_METHOD'] == 'GET' ) { /* Prepare here response data to $response_struct */ ... $return_val = json_encode($response_struct); header("Content-type: application/json"); // CORS header header("Access-Control-Allow-Origin: *"); echo $return_val; } else if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') { // Reply with headers allowing CORS header("Access-Control-Allow-Origin: *"); if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD'])) header("Access-Control-Allow-Methods: GET, OPTIONS"); if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'])) header("Access-Control-Allow-Headers: {$_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}"); exit(0); } ...
Activity
Hi Ari,
I guess you are sending the request to the front-end (account.lab.fiware.org). Here we have not CORS enabled you the behaviour you get is the expected.
I recommend you to use the request explained in http://fiware-idm.readthedocs.org/en/v5.1.1/oauth2.html#get-user-information-and-roles to retrieve the user information from an OAuth2 token. You won't have CORS problems with it.
If you want to use request to /user (using keystone tokens) you have to send it to Keystone endpoint cloud.lab.fiware.org:4730
BR
Tried
GET https://cloud.lab.fiware.org:4730/user?access_token=[Token from Implicit Grant Authorization Request]
Got result
An error occurred during a connection to cloud.lab.fiware.org:4730. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG
Are there reasons not to enable CORS in the account.lab.fiware.org? It seems to supply the needed information nicely to our backend in response to the access_token. Why not to give the information also to clients?
Hi, the correct request is:
GET https://account.lab.fiware.org/user?access_token=[Token from Implicit Grant Authorization Request]
BR
Tried (using XMLHttpRequest in the client at POI-DP website by Firefox)
GET https://account.lab.fiware.org/user?access_token=[Token from Implicit Grant Authorization Request]
Got result
(nothing)
However, if I sent that using RESTClient of my desktop browser, I got the data. I understand that this behaviour is due to missing CORS support.
-> Missing CORS support limits seriously the usability of the KeyRock authentication service.
Please, check that you are correctly sending the request. It is working for me (with curl).
BR
Yes. The request is working with curl and other stand-alone ways to send it. However, there are special considerations about cross-origin service, if the request is sent using XMLHttpRequest from a web client (page) loaded from other domain. The browser (Firefox, Chrome, Safari, ...) running the web client requires the alien (e.g. authentication) server to respond with special CORS headers for security purposes. Without proper CORS headers the browser does not let the response go through to the client program. https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Hi Ari,
yes, I know what CORS means. But as I said before, we have not it enabled in Horizon (Keyrock's front-end). I will include it as a feature to be explored in the future. We have to evaluate the impact it would have.
Thanks for the suggestion.
BR
Hi Alvaro.
I am very surprised that there is such opposition to adding CORS support to KeyRock, which makes it essentially unusable from client applications running in the Web browser. Unfortunately, this is most of the GE in the WebUI chapter.
I have decided to raise the issue in the TSCnext week as I think this is something that is highly relevant for FIWARE and we need to make a decision if we can really leave Web applications out in the dark regarding authentification. Funny enough Ari is supporting other Oauth services just fine (Google).
I would like to ask you to reconsider your approach, we would hate t have to report to users that we cannot support authentification by FIWARE's own authentification service and have to use Google of such instead. I would be happy to set up a call to discuss this issue in more detail
Thanks you for your consideration.
Hi Philipp,
as I said, we were exploring this new feature. It will be ready during the current release.
BR
Blocks WEB-900. Cannot show the logged-in person's name in the POI client.