Navigate directly from form POST response without chicanery

[ehenighan]

Currently you can include form data in a GET as part of a navigation action, but you can't POST. If you do it with a GET the (potentially confidential) form data goes in the POST body. This means that in order to navigate on form POST success, you have to return a fragment with an on-load trigger to do the navigation.

I understand why you wouldn't want the routing to include anything other than the URL, but it's 90% possible to do this with a custom 'post-navigate' behaviour where you pull the form data out from the relevant form and submit it yourself through whatever fetch wrapper you passed in originally - if the server returns/redirects to a navigator, you can parse the document out directly using a clone of the parser object. However, you can't then trigger the navigation just by calling the updateRoot function with the new document, sadly.

What would be really helpful is if there was a way to hook into the navigator from a custom behaviour directly and possibly even feed it a navigation document retrieved via a side channel - then creating a custom 'post-navigate' behaviour would be pretty easy and you could one-shot navigate on form submission instead of having to do the ungainly double-bounce.

Alternatively, any ideas about graceful redirect handling when the server side decides to issue a redirect - e.g. if the session is expired from the server? If you're caught on a form submission when that happens, it doesn't deal with the response very nicely. In my head it would be nice if the client could watch for e.g. something like a specialist header from the server to indicate it's a deliberate forced re-navigation, and then fire a navigate event to reload the screen stack instead of whatever it was aiming for. I'm sure that would cause a whole host of problems elsewhere though.

[adamstep]

Hi @ehenighan . We recently had a similar discussion internally, some engineers similarly requested the idea to support navigation actions with a POST request that includes the form body. For the Instawork app, we do it how you describe (return a fragment that either shows an error if the submitted form has an error, or includes a behavior to navigate to the next screen).

(Note that in terms of confidential information, I don't think there's much of a security benefit of a GET vs POST, someone intercepting the traffic will be able to pull the data out of either request. Of course, there are other reasons to use a POST, since the semantics affect things like caching, logging sensitive data on the server, etc.)

I think the main hangup I have for supporting POST for navigation actions is how to handle the reload action. For GET requests, we simply make the request again, no problem. But what does reload mean when the screen was requested via POST? In a web browser, reloading or navigating back to a page requested via POST shows an annoying dialog to confirm form resubmission. I'd like to avoid that in Hyperview.

Some options we're considering:

1. reload will always make a GET request to the URL used for POST. This requires support on the server side, since the endpoint will need to support both methods.
2. A POST request can return a 302 Found status redirecting to a URL in the Location header, we make a GET request to that URL to load the content for the new screen. A reload on that screen will make a GET request to that same URL.

I think option 2 is a cleaner, but it means the client would need to enforce that a POST request for a navigation action returns a 302? What if there's a validation error and the submitted data is not accepted by the server? With option 1 there's no need for special handling on the client, but it's a potential gotcha for developers. What do you think?

I'm curious to understand more about the solution you're proposing for a post-navigate behavior, I'm not sure I fully get it. Could you share an example snippet of the XML markup and requests to demonstrate how it would work?

[ehenighan]

Hiya,

Yeah, similar sorts of worries as I had really.

So my two rough ideas, let's say we're talking about a logout action, and for [reasons] it has to be a POST. The server knows that the logout action must always cause a navigator reset on the client, so:

1. it would be nice to tell the client that declaratively in the markup, something like:

<text action="post-navigate" href="/logout">Log Out</text>

The behaviour handler for that would do a document load rather than an element load, but with the form body extracted from the parent/target form (did this for event-driven declarative form validation, that bit is fairly simple) and sent up as required (not needed for the logout example unless you need a CSRF token), expect only a navigator element in the doc, and then hand it off to the navigation service essentially as a replacement of the whole navigation tree.

I couldn't implement that last step because I couldn't find a way to bully the custom behaviour framework into letting me access the navigator object in the root props.

So that would be one way to make that behaviour declarative, but I actually think there's a more general thing that would possibly be better:

2. Server Knows Best - I can make the standard logout action declarative in the above manner, but if I e.g. want to add to my web portal a security page that lets me sign out on my mobile devices remotely, sure I can send a push notification with a deep link to trigger logout, but if that app installation makes a server call in the meantime the server is going to send a redirect response to the base unauthenticated navigator and I'd like the app to exit to the login page cleanly.

So really if the app receives a navigator document instead of the fragment element it's expecting, I want it to just drop everything and navigate because the server says so - potentially behind a 'No, I Really Mean It' custom response header for backwards compatibility.

That would mean that the logout POST case is just like every other - try it, server responds with 302, fetch implementation follows the redirect transparently, navigator document is loaded instead of the expected fragment element, response header says it's deliberate, so we emit an event for useful UI hooks like showing a loading spinner, and then navigate as instructed.

This would also work really nicely for logging in as well - and in particular it would be a big bonus for the confidential-client OAuth2 flow I've just finished hooking in because there's just too much redirecting in there already, so if the server could even cut out some redirects and return navigator responses directly it would make the flow a lot more responsive.

Does that make a bit more sense? Don't have a code example conveniently to hand, I'm afraid.

[ehenighan]

Hi @adamstep,

Think I've got a fairly easy solution to this for the server-side session expiry case:

1. When your server wants to force a reset of the navigation tree to the initial navigation, such as when the server has determined that the session should be expired, return a custom header like X-Force-Hyperview-Navigation-Reset on the final redirected response.
2. In your fetch wrapper implementation, check for that header on every response, and if found use the Hyperview Events class to emit a force-reset-navigation event
3. Ensure that your base page templates all include a behaviour which listens for the force-reset-navigation event and carries out a navigate action to the base navigator document URL.

The above is working cleanly for my most important needs (server-side session expiry) with about ten lines of code in total across the back end and native app. However, in theory I think you could do something more advanced/sneaky to read an arbitrary navigation response from the body and use it directly, something like:

1. Detect the header in your fetch wrapper and extract the navigation definition from the response body; cache it somewhere that's going to be available to custom behaviours
2. Fire an event to trigger a custom behaviour which reads the navigation definition from the shared cache and dumps it into the DOM somehow, inside a hidden element with an ID like forced-navigation-container - might need to write a custom component as well to act as a listener/container for this code
3. Fire an event from the custom behaviour which causes a navigate action with href set to #forced-navigation-container to load the cached navigation definition locally

It's a bit of a Rube Goldberg event chain and I haven't experimented with it, but it might be a viable way to auto-navigate from redirected server responses without more network overhead, and flexibly based on the contents of the server response. There might be some restrictions in the API which make it impossible though - can you do a navigate action with a #-prefixed URL, do you need to make the local ID unique somehow to bust through any internal caches of previously-hit navigation URLs, etc.? I might give it a try another time and see how it goes.

A slight tweak to the above would be to have some special URL for this case, such as /local-forced-navigation which is intercepted by the fetch implementation and just returns the cached response body:

1. Detect the header in your fetch wrapper and extract the navigation definition from the response body; cache it somewhere
2. Fire an event to trigger a custom behaviour which tries to navigate to /local-forced-navigation
3. Intercept the call to /local-forced-navigation in the fetch wrapper; return the cached response body

This might be simpler to implement, and avoids messy DOM manipulation and a few layers of Rube Goldberg event firing.

[ehenighan]

Yep, that last option works fine:

1. When the server wants to return a navigation document instead of whatever the client asked for, add a custom header to the response
2. Change the fetch wrapper to look for that custom header
3. When found, cache the response (service worker, local storage, const cache = [], etc. and fire a force-reset-navigation Hyperview event
4. Page template includes a behaviour listener for force-reset-navigation events which does an immediate navigate to /local-forced-navigation
5. Fetch wrapper intercepts request to /local-forced-navigation and returns the cached response containing a navigator document, instead of hitting the server again.

Deals with session timeouts gracefully and should also deal in the same way with arbitrary other 'surprise' forced-navigation responses from the server.

Depending on how behaviour listeners work on inactive screens, may need to do something to make sure if you have multiple screens from the same template cached, the navigation-reset behaviour isn't fired multiple times.