Fix a few more regressions from #4235. #4266
Conversation
For zulip#4146, but also to fix a recent regression from 865914f, like we did in b3af772.
| const rawUpdateEvents = JSON.parse(decodedData); | ||
| const updateEvents: WebViewUpdateEvent[] = rawUpdateEvents.map(updateEvent => ({ | ||
| ...updateEvent, | ||
| // A URL object doesn't round-trip through JSON; we get the string | ||
| // representation. So, "revive" it back into a URL object. | ||
| ...(updateEvent.auth | ||
| ? { auth: { ...updateEvent.auth, realm: new URL(updateEvent.auth.realm) } } | ||
| : {}), | ||
| })); |
There was a problem hiding this comment.
Hmm, kind of ugly, isn't it. :-/ Seems fine for a workaround, and I don't have any immediate ideas for a way to do this (and the similar spot in handleInitialLoad) more cleanly without a fair amount more code; but we'll want to keep an eye on this area whenever adding more complexity to it.
There was a problem hiding this comment.
Yeah, my thoughts exactly. 😦
Hmm! Now that you mention that, I do seem to recall finding that some classes of server API routes tolerated duplicate slashes, while others didn't, just because they went through different pieces of infrastructure code that handled that case differently. The web auth flows certainly use some distinctive pieces of infrastructure code, so I guess it fits that they might be in the group that tolerates such variations in the URL while our main API endpoints aren't. |
Explanations in the commit messages.
For the second (doubled slashes in Apple auth endpoint), following Greg's comment at #4265 (comment) — chat.zulip.org seems perfectly happy to accept the double-slash version, like it did before cfebe3f 😆. At first I was confused about why it seemed to work both before and after my commit here. Anyway, that's probably why.