<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div>
<blockquote type="cite" class="">
<div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The
URL is not changed to match that of the subflow, it stays set to the original flow's path. Yes, it's weird, until you get what it's doing.</span></div>
</blockquote>
</div>
<br class="">
<div class="">I think that actually makes precise sense now, not just the fact but also the reason. How you get served is calculated relative to where you entered. The client is implicitly tracking where it came in using that.</div>
<div class=""><br class="">
</div>
<div class="">At least 4 different persistence mechanisms following at least 3 different persistence models -- HTTP requests, URLs/parameters, cookies, HTML 5 -- is where it got gross fast. They didn't choose to use cookies or local storage, and I'm sure there
are reasons, whether dumb client or efficiency.</div>
<div class=""><br class="">
</div>
<div class="">Neither the /you/are nor the flowExecutionKey is meaningful in isolation, and from the application's POV, it's all in quasi-isolation. These queries just show up.</div>
<div class=""><br class="">
</div>
<div class="">This is the long story when I said "state is confusing". I just have to think of the entire "/idp/you/are?flowExecutionKey=here" as the accessed resource and then start tracing from that point, but I can't really expect to be able to trace that
down to the actual state as a human.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class=""><span class="" style="display: inline !important;">A user could access it, yes, and get an error, but they would never know to do it, and if they do nothing breaks, they just see an error that can be changed into whatever people
want it to be.</span></blockquote>
</div>
<div class=""><span class="" style="display: inline !important;"><br class="">
</span></div>
<div class="">What assumptions can I make regarding the safety of the input to Webflow? If this is standard Webflow, "RTFM" will suffice. I saw CDATA back in your 3.3 authentication examples, though.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class=""><span class="" style="display: inline !important;">There are very powerful things you can do while totally ignoring the internals, but writing flows is not one of them.</span></blockquote>
</div>
<div class=""><span class="" style="display: inline !important;"><br class="">
</span></div>
<div class="">And you can't really detach the other things completely. I wish I had joined the fight against some of the scope creep more assertively or pushed decoupled identity harder. Much of the complexity comes from the interactions between features,
and either one of those would have limited it.</div>
<div class=""><br class="">
</div>
<div class="">This does give me great hope for identity getting decomposed into smaller services eventually, ironically. The alternative is actually harder.</div>
</body>
</html>