iOS redirect / rendering problem
Bob Nemec <[email protected]> Sat, 30 Jul 2022 13:59:41 +0000 (UTC)
| Newsgroups | gmane.comp.lang.smalltalk.squeak.seaside |
|---|---|
| Message-ID | <[email protected]> |
--===============6533320246434423573== Content-Type: multipart/alternative; boundary="----=_Part_3245795_624897383.1659189581976" ------=_Part_3245795_624897383.1659189581976 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We're having a problem with physical iOS devices (works fine on Chrome virt= ual device) where a final Seaside redirect is not happening after an Azure = SSO redirect.=C2=A0I'd like to understand what triggers the Seaside redirec= t: I can see it in normal rendering, but I've never had to dig into it like= this before.=C2=A0 When I log from a non-iOS device I see...1: WAApplication>>handleFiltered: = application URL=C2=A0 - self requestContext redirectTo: 'https://login.micr= osoftonline.com/...'=C2=A0=C2=A0 - redirects back to our app URL with an ac= cess token2: WAApplication>>handleFiltered: application URL with MS access = token & no _s & _k values=C2=A0=C2=A0 - validate token with Azure=C2=A0=C2= =A0 - save user info in new WASession=C2=A0=C2=A0 - finish render3: WAAppli= cation>>handleFiltered: application URL with _s & _k plus callback values l= ike: &2=3D2160&1=3D3840&3=3Dfalse=C2=A0=C2=A0 - WAResponse>>location: appli= cation URL with _s & new _k and no callback values=C2=A04: WAApplication>>h= andleFiltered: application URL with _s & _K=C2=A0=C2=A0 - finish render=C2= =A0=C2=A0With iOS step 3 does not happen; I'd like to know what triggers it= normally.=C2=A0 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 diffe= rence between the two.=C2=A0 Thanks for any help (I'll cross post on the the Seaside mailing list and Di= scord) Bob Nemec ------=_Part_3245795_624897383.1659189581976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div class=3D"yahoo-style-wrap" style=3D"font-fami= ly:lucida console, sans-serif;font-size:13px;"><div dir=3D"ltr" data-setdir= =3D"false"><div><div>We're having a problem with physical iOS devices (work= s fine on Chrome virtual device) where a final Seaside redirect is not happ= ening after an Azure SSO redirect. </div><div>I'd like to understand w= hat triggers the Seaside redirect: I can see it in normal rendering, but I'= ve never had to dig into it like this before. </div><div><br></div><di= v>When I log from a non-iOS device I see...</div><div>1: WAApplication>&= gt;handleFiltered: application URL</div><div> - self requestContext r= edirectTo: 'https://login.microsoftonline.com/...' </div><div> -= redirects back to our app URL with an access token</div><div>2: WAApplicat= ion>>handleFiltered: application URL with MS access token & no _s= & _k values </div><div> - validate token with Azure </= div><div> - save user info in new WASession </div><div> - = finish render</div><div>3: WAApplication>>handleFiltered: application= URL with _s & _k plus callback values like: &2=3D2160&1=3D3840= &3=3Dfalse </div><div> - WAResponse>>location: applica= tion URL with _s & new _k and no callback values </div><div>4: WAA= pplication>>handleFiltered: application URL with _s & _K </d= iv><div> - finish render</div><div> </div><div>With iOS st= ep 3 does not happen; I'd like to know what triggers it normally. </di= v><div><br></div><div>Just to add to the fun, we have a two WAApplication r= egistered. The default application fails on iOS, the other works fine. I ca= n see no obvious difference between the two. </div><div><br></div><div= >Thanks for any help (I'll cross post on the the Seaside mailing list and D= iscord)</div></div><div><br></div><div dir=3D"ltr" data-setdir=3D"false">Bo= b Nemec</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><br></div></d= iv></body></html> ------=_Part_3245795_624897383.1659189581976-- --===============6533320246434423573== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2Vhc2lkZSBt YWlsaW5nIGxpc3QKc2Vhc2lkZUBsaXN0cy5zcXVlYWtmb3VuZGF0aW9uLm9yZwpodHRwOi8vbGlz dHMuc3F1ZWFrZm91bmRhdGlvbi5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL3NlYXNpZGUK --===============6533320246434423573==--