Let apps offer deep permalinks

[gwillen]

In the Wekan port, there's a place in the UI that looks like it is meant to have a deep permalink to a particular card on a board. (Click the card -> ... -> More -> Link to this card)

But on Sandstorm, it just shows a snippet of text containing the path to the card from the grain's URL. It would be nice if it had a link!

For my purposes, it would be sufficient if the link worked for people who already have access; it doesn't need to convey access. (For a simple one-off fix, that would seem to be the safest route, too; any sort of automatic conveyance of access is going to want a more extensive UX review to avoid confusing people into giving out permissions they didn't intend. Accidental non-conveyance of permissions is more obvious and easily fixed.)

So what I think is needed is either (1) a way for the app to ask what its grain URL is, to build the link, or (2) a way for the app to ask Sandstorm to build a deep link and return it.

(While talking about this, @dwrensha suggested using the setPath API to just change the URL bar. I think that actually IS a good idea, in addition to making the permalinks work; it seems that Wekan is already doing pushState stuff to maintain history when moving between cards, and invisibly changing the location of the grain iFrame -- so all that should be needed is to propagate those (currently invisible) URL changes up to the Sandstorm layer. (I can make that a separate bug if desired.) It would still be nice if the in-UI permalinks worked, but if this is easier it could be a good stopgap.)

Thanks!

(CC @zarvox)

[gwillen]

Update: @mnutt suggests looking at https://github.com/mnutt/davros/blob/master/app/router.js#L19-L21 for a simple way to automate calling setPath at the right time. (Seems like this would be a good global Sandstorm feature!)

[zarvox]

It may be safe to expose the grain ID - I don't think grain IDs are currently a secret.

There is a catch for exposing "the path" when dealing with non-logged-in users: the path in the browser looks like /shared/<apiToken> instead of /grain/<grainId>, where <apiToken> is a redeemable token, probably to help make sure that the page is still viewable on refresh. Exposing that token to the app would constitute breaking confinement. Maybe we could save the most recent token-grain mapping client-side (say, in localStorage) for non-logged-in sessions, and then always redirect to /grain/<grainId> instead?

I guess the other risk is that we don't want to confuse developers and have grains using $SANDSTORM_HOST/grain/<grainId> for internal navigation, because that'd try to open the sandstorm shell inside the grain iframe, which will fail because X-Frame-Options. So we'd have to document that this is only to be used for external deep links.

+1 on helpers for setPath, though the correct hook tends to depend on your client-side router.

[mnutt]

I think this does it for wekan: wekan/wekan#403

I think this would allow both the owner and the receiver to pass permalinks back and forth? It'd require the shared <-> grain redirect to work, though.

[kentonv]

We recently added a postMessage API to allow apps to invoke the sharing dialog. Perhaps we should add a parameter to this that lets them specify a path to add to the sharing link?

(But we should consider whether it's too easy for users to think that they're sharing only that path and not the whole grain. Eventually we will support non-main UiViews for the purpose of sharing a restricted view of a grain securely.)

[paulproteus]

On IRC @gwillen was satisfied by the path containing a /grain/{{grainId}} URL plus a app-specific component.

I've documented that at https://docs.sandstorm.io/en/latest/developing/path/

@gwillen does that meet your needs? Should we keep this open for the hypothetical sharing feature that @kentonv mentioned?