New version of addon Flashcards

2025-05-14 16:10:18

adminsforum@hubzilla.org

oj schrieb den folgenden Beitrag Wed, 14 May 2025 16:10:18 +0200

New version of addon Flashcards

#^https://framagit.org/hubzilla/addons/-/merge_requests/443

Please see the comments there.

In short...

There seems to be a limitation if fep-61cf is implemented on the browser side. The JavaScript throws errors if the web server is not configured to accept cross origin resource sharing (CORS)? Any ideas on this?

show all 5 comments

2025-05-15 16:54:01

oj@raspi.digitalesparadies.de

May be fetch(url) is the wrong used case for FEP-61cf because FEP-61cf is ment to be used for window.location.assign(url); only?

In other words, should FEP-61cf be used to redirect a user to a different server only?

2025-05-15 22:32:11

oj@raspi.digitalesparadies.de

The question is a bit obsolete because it is an observation of how OWA it is implemented.

At least it might be helpful to know for some people reading this forum.

2025-05-16 08:23:21

Mario Vavti

mario@hub.somaton.com

@oj have you tried fetch(url, { credentials: 'include' })

2025-05-17 00:14:44

tombeau

tombeau@ein-hub-von-vielen.de

No.

I guess the web server will still not send the Access-Control-Allow-Origin header in the redirect.

See also the comment in the merge request:

The "funny" thing is, the "network" in the developer tools of Firefox and Chromium shows the url (containing /magic?, owa=1, bdest=....) that the JavaScript should use to get an owa token. But the call of the function fetch(..) itself throws an error and there is no way to get the redirect url from the response. (The server side PHP implemention of Hubzilla is not limited by this behavior of modern web browsers.)

I closed the merge request because another version will follow.

Please see also my comment in #^https://hubzilla.monster/display/e6163ebb-e5c8-4ec1-9ede-9fe00abf373f

2025-05-17 00:21:45

tombeau

tombeau@ein-hub-von-vielen.de

My browser has problems to get redirected to hubzilla.monster, #^https://hubzilla.monster/display/e6163ebb-e5c8-4ec1-9ede-9fe00abf373f.

Therefor a copy of my comment there...

In the meantime I found another solution. The browser will only talk to it's home instance, and the home instance (server) will

- request api endpoints GET/POST from the contacts (implemented by the addon),
- request cloud files  (built-in feature of Hubzilla)

I should have gone this way from the beginning. The OWA magic is all there in the  existing code of Hubzilla, ready to be used, e.g. in network.php, z_fetch_url(...). There is also a function zid(url) to prepare the url with the parameter like zid=my@myhub.org, stuff like this.

In addition the server-to-server-fetch-approach saves the browser data volume what is especially an advantage when the addon is used on a phone with a slow data connection. Boxes of flashcards can be fetched and merged directly by the server (instead by the phone).

But anyway it might be helpful for others to know that is possible for a web browser to fetch files directly from a different server IF the web server is configured for this.

And - may be - it is helpful to mention it in the FEP-61cf ?!  (Could have saved me time as well.) After all - this is my main message/proposal.