should handle hash bang style urls

[djay]

e.g. https://hydra-vue-f7.netlify.app/#/!/test

Makes it easy to deploy to some services with some frameworks

I don't know if there other schemes that would require further changes to the path but perhaps just treating it like a prefix and appending the path is ok?

e..g entering either https://hydra-vue-f7.netlify.app/#/!/ or https://hydra-vue-f7.netlify.app/#/! as the prefix should work

The Ui should explain its a prefix and any path will be appended to it

[djay]

wasn't fixed. Didn't properly update the iframe url

[djay]

It still doesn't work @MAX-786

If I navigate inside the iframe I end up with a url like

<iframe id="previewIframe" title="Preview" src="https://localhost:5173/?access_token=...4&amp;_edit=false#/!/testpage-tram"></iframe>

If I refresh the editor then I get a url like

https://localhost:5173/testpage-tram?access_token=...&_edit=false#/!

If I navigate using contents then I end up with a url like

<iframe id="previewIframe" title="Preview" src="https://localhost:5173/testpage-tram?access_token=...&amp;_edit=false#/!"></iframe>

All of which are wrong.

Note you can't just test using the local npm run start and seeing if the page comes up because that vite server accepts both /path and /#/!/path type urls but some deployments like I've done with netlify are only going to support urls that don't set a url path.

[djay]

It also seems to have broken navigation in your frontend also. Not sure how.

[djay]

ok. I think I've fixed up changing the hash path and it routing to the right page. in my branch @MAX-786

[MAX-786]

It also seems to have broken navigation in your frontend also. Not sure how.

Again vercel deployment issue Idk why it was pointing this url to 'main' branch deployment of my frontend which i use for testing and i have to manually change its settings after every commit so this url points to 'production' branch deployment...

One more issue i just saw is that, inside frontend if you try window.location.href you will get href of #document of iframe and not the src of the iframe.. why does it concerns us? because if we are accessing token from url then we are taking it from document's href and the iframe's src AND these 2 will get out of sync very easily if you navigate pages using your frameworks routing like React-router and etc. and then document's href of iframe will not have access_token param causing unauthorized 401 error sometimes, and if we say lets keep these both iframe src and href at sync and change src of iframe every time user change's href then we will go back to our iframe reloading everytime when user changes path.

TLDR;

• window.location.href in the frontend returns the href of the iframe's #document, not the iframe's src.
• This can cause problems when accessing access_token from the URL, especially with frameworks like React-router.
• This can lead to unauthorized 401 errors.
• Trying to keep the iframe's src and href in sync can cause the iframe to reload on every path change.
• This reloading brings us back to the original problem.

So the solution of this is that hydrajs should just save the token in cookie at frontend domain (whenever it receives it from url ) and provide it to frontend. This is already done by hydrajs but just needed bit of tweaking bcz of this issue.

[djay]

@MAX-786 I deployed the fixes to my frontend to handle #! url changes properly. So now you can fix it so these urls work.

The auth thing I don't completly understand. but it seems you are suggesting to not use args to indicate that you are in an edit state and instead use hydra.js api. however that means hydra.js needs to be loaded all the time which we discussed is not a something we want to require.

I haven't seen a problem where the frontend forgets its logged in while editing so I'm not exactly sure what problem you are trying to fix or how to reproduce it

My understanding is that if hydra navigates then its adding the auth token to the url. if the frontend navigates then its normally doing so keeping the page still loaded and so keeps its state. If it doesn't then it's probably up to the frontend to set it's own cookie?

[MAX-786]

however that means hydra.js needs to be loaded all the time which we discussed is not a something we want to require.

No no i mean that hydrajs once loaded it should save the essential stuff like token in cookie (with expiry) so next time when user changes the page and if it doesnt find auth token on url it can extract from cookies

[djay]

No no i mean that hydrajs once loaded it should save the essential stuff like token in cookie (with expiry) so next time when user changes the page and if it doesnt find auth token on url it can extract from cookies

yes I understood that part but I'm still not sure what problem that solves. if the frontend is reloaded then it will be done by the AdminUI so the auth token will be put the url wouldn't it? If the frontend reloads itself somehow then even if hydrajs had saved a cookie then the frontend has to know its there and read it, or access some api to read it. either way it's not that much effort for the frontend developer to have just set and get the cookie itself in a way that works for them. hydrajs itself doesn't need the authtoken is it doesn't need to save it.

[djay]

is there a specific scenario where you are seeing reloading happening such that the auth token is no available? if so why has it worked ok up to now and whats changed?

[MAX-786]

trying to replicate the issue but i think it is just on NEXTjs bcz it rarely happens, like assume you are on a path /1 and you go to /2 then go to edit and changed something came back and now you move back to /1 sometimes this loads empty giving 401 error in console and if you inspect the iframe you will see that iframe src got the params but #document doesn't , right now i saw it very rarely happens and simply reloading it fixes it

[djay]

fixed by #126

[djay]

@MAX-786 this is still not fixed. it is still not appending the path the end of the url

https://hydra.pretagov.com/test

[MAX-786]

I don't know if there other schemes that would require further changes to the path but perhaps just treating it like a prefix and appending the path is ok?

The problem is ?auth_token=... because everything after '#' in a url is treated like a hash like ${frontendOrigin}/${hash}/?auth_token=... and thus if integrator tries to access this from url search params (as we are doing so) then they will get an empty string. So appending the entered url as a prefix for 'iframe src' will not do it.

I did tried to make this work in other ways like taking the hash or whatever is passed on while typing in URL and then doing something like : ${frontendOrigin}?auth_token=.../${hash}/${path} (here hash = #/! works with f7 but it will break for other frameworks because now the path is always '/' since now other frameworks sees it as 'hash'

One obvious solution is to make vercel deployment also support like {origin}/{path} like it does if you run the f7 locally,

But to remove this limitation of having this type of routing supported by the frontend, we can do this is that have a way to tell adminUI that I am gonna use hash type of routing so append the path after this prefix and add params before this and so adminUI will remember this for particular frontends and thus do the routing and adding params normally for others.

[MAX-786]

I think one quick solution would be to have f7 vercel deployment supports custom paths

[djay]

In URIs with a query and a fragment, the fragment follows the query.

https://en.m.wikipedia.org/wiki/URI_fragment

So what that means is you parse the base url. And if there is a fragment present then put the path in the fragment and add that at the end by using the URL API to construct a new url. Since #! Always seems to at least have the ! In it then this should work. If there is no fragment then add the path to the path when you reconstruct the url. We can document this in the readme .

If that doesn't work then we can use a replacement text but I don't think this will be needed.

Since you are reconstructing the url then if the user puts in any search Params of their own then you should probably include them in addition to the ones we are adding. Not useful for this use case though.

[djay]

was fixed