Uploaded image for project: 'Help-Desk'
  1. Help-Desk
  2. HELP-6908

FIWARE.Question.Tech.Apps.ApplicationMashup.IdMIntegration.IncompleteOrganizationList

    Details

      Description

      Created question in FIWARE Q/A platform on 12-07-2016 at 20:07
      Please, ANSWER this question AT http://stackoverflow.com/questions/38336192/x-auth-token-sent-from-wirecloud-widget-does-not-correspond-with-x-auth-token-he

      Question:
      X-Auth-Token sent from Wirecloud widget does not correspond with X-Auth-Token header that came from Wilma PEP Proxy

      Description:
      In our Wirecloud widget we want to pass the logged in users access_token from Keyrock idm to our Wilma PEP Proxy, which in turn must be sent to our API. This is the call in our widget:

      if (MashupPlatform.context.get('fiware_token_available')) {
      MashupPlatform.http.makeRequest(url, {
      //method: "GET",
      requestHeaders:

      { "Accept": "application/json", "X-FI-WARE-OAuth-Token": "true", "X-FI-WARE-OAuth-Header-Name": "X-Auth-Token", }

      ,
      onSuccess: function(response)

      { updateWidget(response.responseText); }

      }); }

      The access_token in the header is valid (tested it with Postman) and i can retrieve the logged in users details, such as organization, roles etc...:

      {
      "organizations": [
      {
      "website": "",
      "description": "test",
      "roles": [

      { "name": "testRole1", "id": "23456" }

      ,

      { "name": "testRole2", "id": "1234567" }

      ],
      "enabled": true,
      "id": "testtest",
      "domain_id": "default",
      "name": "organizationName"
      }
      ],
      "displayName": "user1",
      "roles": [],
      "app_id": "1234567890",
      "email": "email@email.com",
      "id": "user-1"
      }

      However, the access_token being sent from our Wilma PEP Proxy to our API is totally different, it's like the incoming access_token is totally being ignored. When i do a call to retrieve the users information based on this access_token this is returned:

      { "organizations": [], "displayName": "user1", "roles": [], "app_id": "1234567890", "email": "email@email.com", "id": "user-1" }

      Why are the access_tokens different, shouldn't the access_token being placed in the HTTP header in the request of our widget be the same as the access_token that our API is getting from the Wilma PEP Proxy? We need to be able to retrieve organizations for the logged in idm user, now this is empty which causes our own API call to fail.

      Any help would be greatly appreciated .

        Activity

        Hide
        backlogmanager Backlog Manager added a comment -

        2016-07-12 21:05|CREATED monitor | # answers= 0, accepted answer= False

        Show
        backlogmanager Backlog Manager added a comment - 2016-07-12 21:05|CREATED monitor | # answers= 0, accepted answer= False
        Hide
        backlogmanager Backlog Manager added a comment -

        2016-07-13 12:05|UPDATED status: transition Answer| # answers= 1, accepted answer= False

        Show
        backlogmanager Backlog Manager added a comment - 2016-07-13 12:05|UPDATED status: transition Answer| # answers= 1, accepted answer= False
        Hide
        backlogmanager Backlog Manager added a comment -

        2016-07-13 15:05|UPDATED status: transition Answered| # answers= 1, accepted answer= False

        Show
        backlogmanager Backlog Manager added a comment - 2016-07-13 15:05|UPDATED status: transition Answered| # answers= 1, accepted answer= False
        Hide
        backlogmanager Backlog Manager added a comment -

        2016-07-15 18:05|UPDATED status: transition Finish| # answers= 1, accepted answer= True

        Show
        backlogmanager Backlog Manager added a comment - 2016-07-15 18:05|UPDATED status: transition Finish| # answers= 1, accepted answer= True

          People

          • Assignee:
            aarranz Álvaro Arranz
            Reporter:
            backlogmanager Backlog Manager
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: