[Seaside] iOS redirect / rendering problem

Tue Aug 2 19:27:03 UTC 2022

Hi Bob,

I don’t know how sensitive the request/response data is, but could you create HAR archives of the communication? In Chrome the dev-tools have a Network Tab with the two Arrows for import/export:
[cid:image001.png at 01D8A6B6.9A8CFF60]

You may also need to make sure the “Preserve Log” checkbox is checked. Otherwise any redirect would remove the previous requests.

If the problem only happens with Safari it may not be a Seaside-specific-Problem and I’d rather just have a look at the plain HTTP that’s going back and forth.

Karsten

Von: seaside [mailto:seaside-bounces at lists.squeakfoundation.org] Im Auftrag von Bob Nemec
Gesendet: Dienstag, 2. August 2022 20:53
An: Seaside - general discussion <seaside at lists.squeakfoundation.org>
Betreff: Re: [Seaside] iOS redirect / rendering problem

To clarify, I do see the 302 redirect being set, but what I can't see is any material difference in the response content. I am trying to see if not coding the default application in the URL will satisfy iOS, since it is only the default app that is having the issue. So https://ourapplication.com/appname?s_... vs. https://ourapplication.com/?s_... Not looking at it as as fix, but curious to see if it makes a difference.

- WACallbackProcessingActionContinuation>>redirectToContinuation:
- WAResponse>>redirectTo:
- WAResponse>>found --> self status: WAResponse statusFound
- WAResponse statusFound = 302

On Tuesday, August 2, 2022 at 02:26:08 p.m. EDT, Bob Nemec <bobn at rogers.com<mailto:bobn at rogers.com>> wrote:

Hey Karsten,
Trying to find the difference between the two responses is where I stuck now: from what I can see they are the same... the normal expected rendered content in each case. Just that in the iOS example, the Seaside redirect that answers the content does not happen.

And it is also where my Seaside internal knowledge stops: I do not yet know how Seaside triggers each render redirect. I thought it answered a 302 response, but the content I trace shows a 200 / OK response. Once I understand how the redirect is code, I figure I can try changes to make iOS happy.

Bob
On Tuesday, August 2, 2022 at 10:31:36 a.m. EDT, Karsten Kusche <karsten at heeg.de<mailto:karsten at heeg.de>> wrote:

Hi Bob,

what’s the content produced by the render-phase that’d initiate the following callback-phase?

Kind Regards
Karsten
—

Georg Heeg eK

Wallstraße 22

06366 Köthen

Tel.: 03496/214328

FAX: 03496/214712

Amtsgericht Dortmund HRA 12812

Am 2. August 2022 um 15:40:47, Bob Nemec (bobn at rogers.com<mailto:bobn at rogers.com>) schrieb:
fwiw: looking at WARenderPhaseContinuation>>processRendering: I see the same content for both the iOS and Windows initial request. And I see that with iOS the following WACallbackProcessingActionContinuation does not happen, as it does with Windows... that's where I'm stuck.

Bob

On Saturday, July 30, 2022 at 11:00:00 a.m. EDT, Bob Nemec <bobn at rogers.com<mailto:bobn at rogers.com>> wrote:

Thanks... I set up to do the debugging, and it turns out that the problem also happens with Safari on a mac (but not Chrome). That makes it easier to work with. On an iPhone and iPad the problem happens with any browser.

Bob

On Saturday, July 30, 2022 at 10:18:13 a.m. EDT, Karsten Kusche <karsten at heeg.de<mailto:karsten at heeg.de>> wrote:

Hi Bob,

when you plug your iOS device into a USB cable and connect it to a mac, then you can go to Mac-Safari -> debug menu -> 3rd or 4th entry in the menu should be the name of your device. There you can open the debugger on a tab of your iOS Safari and debug everything from the Browser side.

Maybe it helps already.

Kind Regards
Karsten

—

Georg Heeg eK

Wallstraße 22

06366 Köthen

Tel.: 03496/214328

FAX: 03496/214712

Amtsgericht Dortmund HRA 12812

Am 30. Juli 2022 um 15:59:56, Bob Nemec (bobn at rogers.com<mailto:bobn at rogers.com>) schrieb:
We're having a problem with physical iOS devices (works fine on Chrome virtual device) where a final Seaside redirect is not happening after an Azure SSO redirect.
I'd like to understand what triggers the Seaside redirect: I can see it in normal rendering, but I've never had to dig into it like this before.

When I log from a non-iOS device I see...
1: WAApplication>>handleFiltered: application URL
  - self requestContext redirectTo: 'https://login.microsoftonline.com/...'
  - redirects back to our app URL with an access token
2: WAApplication>>handleFiltered: application URL with MS access token & no _s & _k values
  - validate token with Azure
  - save user info in new WASession
  - finish render
3: WAApplication>>handleFiltered: application URL with _s & _k plus callback values like: &2=2160&1=3840&3=false
  - WAResponse>>location: application URL with _s & new _k and no callback values
4: WAApplication>>handleFiltered: application URL with _s & _K
  - finish render

With iOS step 3 does not happen; I'd like to know what triggers it normally.

Just to add to the fun, we have a two WAApplication registered. The default application fails on iOS, the other works fine. I can see no obvious difference between the two.

Thanks for any help (I'll cross post on the the Seaside mailing list and Discord)

Bob Nemec

_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org<mailto:seaside at lists.squeakfoundation.org>
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org<mailto:seaside at lists.squeakfoundation.org>
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org<mailto:seaside at lists.squeakfoundation.org>
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org<mailto:seaside at lists.squeakfoundation.org>
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20220802/096e926c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 14533 bytes
Desc: image001.png
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20220802/096e926c/attachment-0001.png>