Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getUser hangs when profile attribute has a large value #56

Open
redbmk opened this issue Jun 12, 2018 · 4 comments
Open

getUser hangs when profile attribute has a large value #56

redbmk opened this issue Jun 12, 2018 · 4 comments
Assignees
Labels

Comments

@redbmk
Copy link

redbmk commented Jun 12, 2018

When retrieving a profile that contains very large values, the getUser function fails to return. To recreate this, create a custom string attribute (avatar for example). Then set the value to something large - in my case I used a 600kb image converted to a data URI (there are online tools to make this easy, such as https://dopiaza.org/tools/datauri/index.php).

If this is done with user.update() then the next call to getUser for that user will return the right value. However, if the user is not already in cache and needs to be fetched from the API, then getUser will never return.

It's not clear to me yet if this is a problem with the API not returning, or if it's a problem with this node module. When looking at the user's profile in the Okta admin panel, the string is viewable and can be edited. After clearing the value, the getUser function will work again for that user.

@redbmk redbmk changed the title getUser hangs when profile attribute has a large value getUser hangs when profile attribute has a large value Jun 12, 2018
@robertjd
Copy link
Contributor

Thanks @redbmk for the report, were you able to determine if this hang is form the API or not? Can you try with Curl or Postman and let us know?

@robertjd robertjd self-assigned this Jun 12, 2018
@redbmk
Copy link
Author

redbmk commented Jun 12, 2018

Looks like it does come back using the raw API, and it includes the full Data URI. It does take over a second, so it's not the fastest thing in the world, but the node module doesn't return at all. If I just get the headers without receiving any data then it's closer to half a second, so a good chunk of that is probably just the download.

$ time curl $ORG_URL/api/v1/users/$USER_ID -H "authorization:  SSWS $API_TOKEN" -s0 > /dev/null

real    0m1.263s
user    0m0.056s
sys     0m0.013s

$ time curl $ORG_URL/api/v1/users/$USER_ID -H "authorization:  SSWS $API_TOKEN" -s0 -I > /dev/null

real    0m0.530s
user    0m0.026s
sys     0m0.009s

If I clear out the data, then the time moves to about half a second with or without the payload:

$ time curl $ORG_URL/api/v1/users/$USER_ID -H "authorization:  SSWS $API_TOKEN" -s0 > /dev/null

real    0m0.479s
user    0m0.019s
sys     0m0.006s

$ time curl $ORG_URL/api/v1/users/$USER_ID -H "authorization:  SSWS $API_TOKEN" -s0 -I > /dev/null

real    0m0.478s
user    0m0.017s
sys     0m0.006s

@robertjd
Copy link
Contributor

Thanks @redbmk , I'm going to triage this for a closer look

@robertjd robertjd added Triaged and removed Analysis labels Jun 12, 2018
@oleksandrpravosudko-okta
Copy link
Contributor

This appears to be caused by Response.clone issue.
Short-term workaround is to disable caching or provide .clone()-free cache middleware implementation.

Internal Ref: OKTA-410746

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants