Conversation
| }); | ||
|
|
||
| const generateSessionToken = useCallback(() => { | ||
| return uuidv4({ rng: randomGenerator }); |
There was a problem hiding this comment.
As we had an issue concerning usage of crypto.getRandomValues on iOS Native devices, we can use a random generator for session token generation which I think is good enough for the given scenario. This change works well on iOS devices.
There was a problem hiding this comment.
I can't think of any reason these need to be cryptographically secure, can you? If not, this seems fine to me 👍
There was a problem hiding this comment.
I can't think of any reason these need to be cryptographically secure, can you? If not, this seems fine to me
Yeah. I don't see any valid reason either to make it so secure.
|
|
||
| if (props.isNewPlacesAPI) { | ||
| request.setRequestHeader( | ||
| 'content-type', |
There was a problem hiding this comment.
On Android native devices, the API request fails with the response message stating that it needs content-type header. Adding the header resolves the issue with Android native devices.
There was a problem hiding this comment.
Can you help me understand why specifically this happens on android and if this is the only fix? As you stated in your App PR, adding this header causes CORS errors - I noticed this on dev too.
There was a problem hiding this comment.
The response (as shared in screenshot below) precisely pointed out this reason and so didn’t dig deeper. But your question on why specifically this happens on Android is interesting. I will take a closer look at this.
There was a problem hiding this comment.
Thanks yeah please do, it is very strange. AFAIK that response is not coming from the server
There was a problem hiding this comment.
Thanks yeah please do, it is very strange. AFAIK that response is not coming from the server
@rafecolton That's correct. The response comes from android native implementation as referenced in the screenshot below. Since we have stringified the request body of our POST request, android native implementation expects content-type to be sent. The only way to programmatically avoid this response is to avoid JSON.stringify but it does not seem to be a viable option for us.
So, It looks like we have to address the issue in desktop platform along with the content-type and we are discussing this here
2 participants
Follow-up PR to this to resolve native platform issues:
content-typeto avoid API request failure on android native devices.