[GH-ISSUE #86] Feature Request: XBEL support (or other file format)

kerem commented

2026-02-25 22:36:06 +03:00

Owner

Originally created by @Lantizia on GitHub (Apr 16, 2018).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/86

Many many moons ago (about 2 or 3 bookmark syncing-related solutions ago)...

I used to be a Firefox user (and may be again some day soon the way Chrome is going)... and used to use a Firefox addon (I can't seem to find what it was called) that could sync Firefox bookmarks against a file you stored on an FTP or WebDAV server. I think it used to offer choices of CSV or XBEL, and I would choose XBEL as it seemed a bit more suitable for the task (an XML schema specifically for bookmarks).

The reason I bring this up is... well...

the "Nextcloud Bookmarks App" it seems is hardly designed for native browser bookmarks in mind (i.e. doesn't do folders, so also can't easily do empty folders, no duplicate bookmarks, descriptions for bookmarks you won't see natively)
Nextcloud (for me anyway) is primarily all about syncing files... I love how my KeePass database is an actual kdbx file that I keep synced across multiple clients (Android, Windows, Linux, macOS) - and all those clients need is basic ownCloud/Nextcloud/WebDAV knowledge to access it. The "Nextcloud Bookmarks App" using a database, kinda flies against that (although likely more optimal) and was likely only done this way as it was only ever intended to be used as a nice web interface.
Lastly I see this projects front page talks about "The goal of this project is to build a browser extension that syncs your browser data with the open source sync and share server Nextcloud.". I'm guessing that means one day you want to do more than just bookmarks, that's great - but the "Nextcloud Bookmarks App" database can't be depended on for this anyway... so you might end up turning to storing files anyway.

Essentially, I'm asking that XBEL (or other file format) on a Nextcloud server, be considered an alternate storage backend for this extension.

None of the Nextcloud-specific code or Chrome/Firefox native bookmark reading/writing code needs to be lost - it's not a brand new project... just one with alternate backend storage.

Thoughts?

Originally created by @Lantizia on GitHub (Apr 16, 2018). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/86 Many many moons ago (about 2 or 3 bookmark syncing-related solutions ago)... I used to be a Firefox user (and may be again some day soon the way Chrome is going)... and used to use a Firefox addon (I can't seem to find what it was called) that could sync Firefox bookmarks against a file you stored on an FTP or WebDAV server. I think it used to offer choices of CSV or XBEL, and I would choose XBEL as it seemed a bit more suitable for the task (an XML schema specifically for bookmarks). The reason I bring this up is... well... - the "Nextcloud Bookmarks App" it seems is hardly designed for native browser bookmarks in mind (i.e. doesn't do folders, so also can't easily do empty folders, no duplicate bookmarks, descriptions for bookmarks you won't see natively) - Nextcloud (for me anyway) is primarily all about syncing files... I love how my KeePass database is an actual kdbx file that I keep synced across multiple clients (Android, Windows, Linux, macOS) - and all those clients need is basic ownCloud/Nextcloud/WebDAV knowledge to access it. The "Nextcloud Bookmarks App" using a database, kinda flies against that (although likely more optimal) and was likely only done this way as it was only ever intended to be used as a nice web interface. - Lastly I see this projects front page talks about "The goal of this project is to build a browser extension that syncs your browser data with the open source sync and share server Nextcloud.". I'm guessing that means one day you want to do more than just bookmarks, that's great - but the "Nextcloud Bookmarks App" database can't be depended on for this anyway... so you might end up turning to storing files anyway. Essentially, I'm asking that XBEL (or other file format) on a Nextcloud server, be considered an alternate storage backend for this extension. None of the Nextcloud-specific code or Chrome/Firefox native bookmark reading/writing code needs to be lost - it's not a brand new project... just one with alternate backend storage. Thoughts?

kerem

2026-02-25 22:36:06 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@marcelklehr commented on GitHub (Apr 16, 2018):

This is an interesting proposal. It's quite simple to add support for other backends in the code and I'm by no means fixated on nextcloud bookmarks as a backend. The big question would be how to make syncing work correctly, as XBEL expects all bookmarks in one file. Syncing would mean replacing the whole file when the changes are actually more granular. e.g. what happens when two clients sync their bookmarks?

@marcelklehr commented on GitHub (Apr 16, 2018): This is an interesting proposal. It's quite simple to add support for other backends in the code and I'm by no means fixated on nextcloud bookmarks as a backend. The big question would be how to make syncing work correctly, as XBEL expects all bookmarks in one file. Syncing would mean replacing the whole file when the changes are actually more granular. e.g. what happens when two clients sync their bookmarks?

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@Lantizia commented on GitHub (Apr 16, 2018):

I think KeePass (I personally use KeePassXC on Windows and Linux and KeePass2Android on my phone/tablet)... handles this by having a lock file - just as an example proposal.

Also side note... KeePass2Android supports Dropbox (along side many others like ownCloud/OneDrive/G-Drive/etc...) but what I find extra interesting is it supports Dropbox again in the sense that it only requests access to a specific folder of 'Apps/Keepass2Android' (this location can't be changed)... which is handy if you don't fancy giving the app full access to the whole thing.

Don't suppose Nextcloud has something similar? So perhaps floccus could just access 'Apps/floccus' to store it's XBEL and/or lock file(s)? Keeps them neatly contained and easy to find for anyone else setting up floccus on other machines (rather than browsing around for a file).

@Lantizia commented on GitHub (Apr 16, 2018): I think KeePass (I personally use KeePassXC on Windows and Linux and KeePass2Android on my phone/tablet)... handles this by having a lock file - just as an example proposal. Also side note... KeePass2Android supports Dropbox (along side many others like ownCloud/OneDrive/G-Drive/etc...) but what I find extra interesting is it supports Dropbox again in the sense that it only requests access to a specific folder of 'Apps/Keepass2Android' (this location can't be changed)... which is handy if you don't fancy giving the app full access to the whole thing. Don't suppose Nextcloud has something similar? So perhaps floccus could just access 'Apps/floccus' to store it's XBEL and/or lock file(s)? Keeps them neatly contained and easy to find for anyone else setting up floccus on other machines (rather than browsing around for a file).

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 17, 2018):

Howdy

I discussed this briefly with Marcel, I am going to try building a file based storage backend, and a php script backend as well. The file based backend I was planning on JSON, I had not considered XBEL, I will look into XBEL. The PHP backend option is for people who use or have inexpensive web hosting accounts just put the script on the site and connect it to a Mysql DB and it will be useful.

I hope to spend some time on it starting next week, I have plans for this weekend.

Stay in touch.

Julian

@jlbprof commented on GitHub (Apr 17, 2018): Howdy I discussed this briefly with Marcel, I am going to try building a file based storage backend, and a php script backend as well. The file based backend I was planning on JSON, I had not considered XBEL, I will look into XBEL. The PHP backend option is for people who use or have inexpensive web hosting accounts just put the script on the site and connect it to a Mysql DB and it will be useful. I hope to spend some time on it starting next week, I have plans for this weekend. Stay in touch. Julian

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@mnalis commented on GitHub (Apr 20, 2018):

This sounds quite interesting. I also used to use syncplaces extension (until firefox changes broke it), which would sync bookmarks in XBEL format on your WebDAV server. It would be great to have such alternative again!

Another nice thing about XBEL (apart from being standard and having all your data,structure, and ordering) is you could use XSLT companion file to format it nicely and display directly in browser (so you could access your bookmarks read-only, preferably .htaccess password protected, even on remote machines if need be, without installing any software)

@mnalis commented on GitHub (Apr 20, 2018): This sounds quite interesting. I also used to use syncplaces extension (until firefox changes broke it), which would sync bookmarks in XBEL format on your WebDAV server. It would be great to have such alternative again! Another nice thing about XBEL (apart from being standard and having all your data,structure, and ordering) is you could use XSLT companion file to format it nicely and display directly in browser (so you could access your bookmarks read-only, preferably .htaccess password protected, even on remote machines if need be, without installing any software)

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@Lantizia commented on GitHub (Apr 24, 2018):

@mnalis Thank you for mentioning SyncPlaces, it was really bugging me I couldn't remember the name of it!

XBEL should definitely be a serious consideration... it was hardly an internationally ratified standard, but it was a step in the right direction of something following a specification at least which had portability between applications. Other than SyncPlaces, the XBEL Wikipedia entry mentions another 5 applications using it.

Additionally... and I'm honestly just saying this because I'm curious how bad an idea this might be...

How does anyone feel about the bookmark folders being real folders and the bookmarks being real files (one file per bookmark). This could be done using the Windows .url file (spec), a macOS .webloc file (spec), or a Linux .desktop file (spec)... or something completely different. But personally (although I'm a Linux user, but I can get around this with a little bash script) I'd say using whatever is most ubiquitous is likely better, and that is .url by far.

It'll likely not be as quick... but an advantage could be that you can use a real file manager (Windows Explorer, Finder, Caja, Nautilus, etc...) to manage and organise your bookmarks. And if it did follow a format the OS understood (.url, .webloc, etc...) then you can just open those files to load the page too. This ordinary file/folder approach could also mean you may be able to use them in OS taskbars too (think back to the old Quick Launch toolbar in Windows).

Just a thought.

But whatever is picked... portability is key! The one thing all these bookmark sync tools have had in common over the years... is they stop being maintained for whatever reason.

@Lantizia commented on GitHub (Apr 24, 2018): @mnalis Thank you for mentioning SyncPlaces, it was really bugging me I couldn't remember the name of it! XBEL should definitely be a serious consideration... it was hardly an internationally ratified standard, but it was a step in the right direction of *something* following a specification at least which had portability between applications. Other than SyncPlaces, the [XBEL Wikipedia entry](https://en.wikipedia.org/wiki/XBEL) mentions another 5 applications using it. Additionally... **and I'm honestly just saying this because I'm curious how bad an idea this might be...** How does anyone feel about the bookmark folders being real folders and the bookmarks being real files (one file per bookmark). This could be done using the Windows .url file ([spec](http://www.lyberty.com/encyc/articles/tech/dot_url_format_-_an_unofficial_guide.html)), a macOS .webloc file ([spec](https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html)), or a Linux .desktop file ([spec](https://specifications.freedesktop.org/desktop-entry-spec/latest/))... or something completely different. But personally (although I'm a Linux user, but I can get around this with a little bash script) I'd say using whatever is most ubiquitous is likely better, and that is .url by far. It'll likely not be as quick... but an advantage could be that you can use a **real** file manager (Windows Explorer, Finder, Caja, Nautilus, etc...) to manage and organise your bookmarks. And if it did follow a format the OS understood (.url, .webloc, etc...) then you can just open those files to load the page too. This ordinary file/folder approach could also mean you may be able to use them in OS taskbars too (think back to the old Quick Launch toolbar in Windows). Just a thought. But whatever is picked... portability is key! The one thing all these bookmark sync tools have had in common over the years... is they stop being maintained for whatever reason.

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 24, 2018):

Lantizia

I have many options available when I get WebDav working including 1
bookmark per file. I am thinking an XML style such as XBEL has
advantages that are easy to work with in JSON.

I am struggling at the moment with WebDav on Chrome, it works on Firefox
right now. So when I get past that we can explore this more.

Thanx

Julian

On Tue, Apr 24, 2018 at 5:57 AM, Lantizia notifications@github.com wrote:

@mnalis https://github.com/mnalis Thank you for mentioning SyncPlaces,
it was really bugging me I couldn't remember the name of it!

XBEL should definitely be a serious consideration... it was hardly an
internationally ratified standard, but it was a step in the right direction
of something following a specification at least which had portability
between applications. Other than SyncPlaces the [https://en.wikipedia.org/
wiki/XBEL](Wikipedia entry for XBEL) mentions another 5 applications
using it.

Additionally... and I'm honestly just saying this because I'm curious
how bad an idea this might be...

How does anyone feel about the idea of 1 bookmark = 1 file? If the folders
were real folders and the bookmarks were a file each (think back the bad
old days of IE and .url files - which I think are still in use today, even
by Chrome). It may not be as quick... but an advantage would be you could
use a real file manager (Windows Explorer, Nautilus, Finder, Caja,
etc...) to manage and organise your bookmarks. And if it did follow
something that already exists (like .url) then you could potentially just
open them by doubling clicking too... potentially allowing you to use the
file/folder structure in other things like taskbars and such (think the old
Quick Launch toolbar). I'm a Linux user myself so I'd have to find a way of
getting to process .url files, but a quick bash script could do that.

Just a thought.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/floccus/issues/86#issuecomment-383890211,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJS39dSCQccF7PQXmaRSXjMOHhyt3lizks5trwUwgaJpZM4TV8wY
.

@jlbprof commented on GitHub (Apr 24, 2018): Lantizia I have many options available when I get WebDav working including 1 bookmark per file. I am thinking an XML style such as XBEL has advantages that are easy to work with in JSON. I am struggling at the moment with WebDav on Chrome, it works on Firefox right now. So when I get past that we can explore this more. Thanx Julian On Tue, Apr 24, 2018 at 5:57 AM, Lantizia <notifications@github.com> wrote: > @mnalis <https://github.com/mnalis> Thank you for mentioning SyncPlaces, > it was really bugging me I couldn't remember the name of it! > > XBEL should definitely be a serious consideration... it was hardly an > internationally ratified standard, but it was a step in the right direction > of *something* following a specification at least which had portability > between applications. Other than SyncPlaces the [https://en.wikipedia.org/ > wiki/XBEL](Wikipedia entry for XBEL) mentions another 5 applications > using it. > > Additionally... *and I'm honestly just saying this because I'm curious > how bad an idea this might be...* > > How does anyone feel about the idea of 1 bookmark = 1 file? If the folders > were real folders and the bookmarks were a file each (think back the bad > old days of IE and .url files - which I think are still in use today, even > by Chrome). It may not be as quick... but an advantage would be you could > use a *real* file manager (Windows Explorer, Nautilus, Finder, Caja, > etc...) to manage and organise your bookmarks. And if it did follow > something that already exists (like .url) then you could potentially just > open them by doubling clicking too... potentially allowing you to use the > file/folder structure in other things like taskbars and such (think the old > Quick Launch toolbar). I'm a Linux user myself so I'd have to find a way of > getting to process .url files, but a quick bash script could do that. > > Just a thought. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/marcelklehr/floccus/issues/86#issuecomment-383890211>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AJS39dSCQccF7PQXmaRSXjMOHhyt3lizks5trwUwgaJpZM4TV8wY> > . >

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 24, 2018):

Lantizia

Sorry this only went to Marcel, so I am sending it out again replied to all.

I have many options available when I get WebDav working including 1
bookmark per file. I am thinking an XML style such as XBEL has
advantages that are easy to work with in JSON.

I am struggling at the moment with WebDav on Chrome, it works on Firefox
right now. So when I get past that we can explore this more.

Thanx

Julian

On Tue, Apr 24, 2018 at 5:57 AM, Lantizia notifications@github.com wrote:

@mnalis https://github.com/mnalis Thank you for mentioning SyncPlaces,
it was really bugging me I couldn't remember the name of it!

XBEL should definitely be a serious consideration... it was hardly an
internationally ratified standard, but it was a step in the right direction
of something following a specification at least which had portability
between applications. Other than SyncPlaces the [https://en.wikipedia.org/
wiki/XBEL](Wikipedia entry for XBEL) mentions another 5 applications
using it.

Additionally... and I'm honestly just saying this because I'm curious
how bad an idea this might be...

How does anyone feel about the idea of 1 bookmark = 1 file? If the folders
were real folders and the bookmarks were a file each (think back the bad
old days of IE and .url files - which I think are still in use today, even
by Chrome). It may not be as quick... but an advantage would be you could
use a real file manager (Windows Explorer, Nautilus, Finder, Caja,
etc...) to manage and organise your bookmarks. And if it did follow
something that already exists (like .url) then you could potentially just
open them by doubling clicking too... potentially allowing you to use the
file/folder structure in other things like taskbars and such (think the old
Quick Launch toolbar). I'm a Linux user myself so I'd have to find a way of
getting to process .url files, but a quick bash script could do that.

Just a thought.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/floccus/issues/86#issuecomment-383890211,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJS39dSCQccF7PQXmaRSXjMOHhyt3lizks5trwUwgaJpZM4TV8wY
.

@jlbprof commented on GitHub (Apr 24, 2018): Lantizia Sorry this only went to Marcel, so I am sending it out again replied to all. I have many options available when I get WebDav working including 1 bookmark per file. I am thinking an XML style such as XBEL has advantages that are easy to work with in JSON. I am struggling at the moment with WebDav on Chrome, it works on Firefox right now. So when I get past that we can explore this more. Thanx Julian On Tue, Apr 24, 2018 at 5:57 AM, Lantizia <notifications@github.com> wrote: > @mnalis <https://github.com/mnalis> Thank you for mentioning SyncPlaces, > it was really bugging me I couldn't remember the name of it! > > XBEL should definitely be a serious consideration... it was hardly an > internationally ratified standard, but it was a step in the right direction > of *something* following a specification at least which had portability > between applications. Other than SyncPlaces the [https://en.wikipedia.org/ > wiki/XBEL](Wikipedia entry for XBEL) mentions another 5 applications > using it. > > Additionally... *and I'm honestly just saying this because I'm curious > how bad an idea this might be...* > > How does anyone feel about the idea of 1 bookmark = 1 file? If the folders > were real folders and the bookmarks were a file each (think back the bad > old days of IE and .url files - which I think are still in use today, even > by Chrome). It may not be as quick... but an advantage would be you could > use a *real* file manager (Windows Explorer, Nautilus, Finder, Caja, > etc...) to manage and organise your bookmarks. And if it did follow > something that already exists (like .url) then you could potentially just > open them by doubling clicking too... potentially allowing you to use the > file/folder structure in other things like taskbars and such (think the old > Quick Launch toolbar). I'm a Linux user myself so I'd have to find a way of > getting to process .url files, but a quick bash script could do that. > > Just a thought. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/marcelklehr/floccus/issues/86#issuecomment-383890211>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AJS39dSCQccF7PQXmaRSXjMOHhyt3lizks5trwUwgaJpZM4TV8wY> > . >

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 24, 2018):

Oops I said:

with in JSON

I meant Javascript.

I had JSON on my mind apparently. :)

Julian

On Tue, Apr 24, 2018 at 7:06 AM, Julian Brown julian@jlbprof.com wrote:

Lantizia

Sorry this only went to Marcel, so I am sending it out again replied to
all.

I have many options available when I get WebDav working including 1
bookmark per file. I am thinking an XML style such as XBEL has
advantages that are easy to work with in JSON.

I am struggling at the moment with WebDav on Chrome, it works on Firefox
right now. So when I get past that we can explore this more.

Thanx

Julian

On Tue, Apr 24, 2018 at 5:57 AM, Lantizia notifications@github.com
wrote:

@mnalis https://github.com/mnalis Thank you for mentioning SyncPlaces,
it was really bugging me I couldn't remember the name of it!

XBEL should definitely be a serious consideration... it was hardly an
internationally ratified standard, but it was a step in the right direction
of something following a specification at least which had portability
between applications. Other than SyncPlaces the [
https://en.wikipedia.org/wiki/XBEL](Wikipedia entry for XBEL) mentions
another 5 applications using it.

Additionally... and I'm honestly just saying this because I'm curious
how bad an idea this might be...

How does anyone feel about the idea of 1 bookmark = 1 file? If the
folders were real folders and the bookmarks were a file each (think back
the bad old days of IE and .url files - which I think are still in use
today, even by Chrome). It may not be as quick... but an advantage would be
you could use a real file manager (Windows Explorer, Nautilus, Finder,
Caja, etc...) to manage and organise your bookmarks. And if it did follow
something that already exists (like .url) then you could potentially just
open them by doubling clicking too... potentially allowing you to use the
file/folder structure in other things like taskbars and such (think the old
Quick Launch toolbar). I'm a Linux user myself so I'd have to find a way of
getting to process .url files, but a quick bash script could do that.

Just a thought.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/floccus/issues/86#issuecomment-383890211,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJS39dSCQccF7PQXmaRSXjMOHhyt3lizks5trwUwgaJpZM4TV8wY
.

@jlbprof commented on GitHub (Apr 24, 2018): Oops I said: >with in JSON I meant Javascript. I had JSON on my mind apparently. :) Julian On Tue, Apr 24, 2018 at 7:06 AM, Julian Brown <julian@jlbprof.com> wrote: > Lantizia > > Sorry this only went to Marcel, so I am sending it out again replied to > all. > > I have many options available when I get WebDav working including 1 > bookmark per file. I am thinking an XML style such as XBEL has > advantages that are easy to work with in JSON. > > I am struggling at the moment with WebDav on Chrome, it works on Firefox > right now. So when I get past that we can explore this more. > > Thanx > > Julian > > On Tue, Apr 24, 2018 at 5:57 AM, Lantizia <notifications@github.com> > wrote: > >> @mnalis <https://github.com/mnalis> Thank you for mentioning SyncPlaces, >> it was really bugging me I couldn't remember the name of it! >> >> XBEL should definitely be a serious consideration... it was hardly an >> internationally ratified standard, but it was a step in the right direction >> of *something* following a specification at least which had portability >> between applications. Other than SyncPlaces the [ >> https://en.wikipedia.org/wiki/XBEL](Wikipedia entry for XBEL) mentions >> another 5 applications using it. >> >> Additionally... *and I'm honestly just saying this because I'm curious >> how bad an idea this might be...* >> >> How does anyone feel about the idea of 1 bookmark = 1 file? If the >> folders were real folders and the bookmarks were a file each (think back >> the bad old days of IE and .url files - which I think are still in use >> today, even by Chrome). It may not be as quick... but an advantage would be >> you could use a *real* file manager (Windows Explorer, Nautilus, Finder, >> Caja, etc...) to manage and organise your bookmarks. And if it did follow >> something that already exists (like .url) then you could potentially just >> open them by doubling clicking too... potentially allowing you to use the >> file/folder structure in other things like taskbars and such (think the old >> Quick Launch toolbar). I'm a Linux user myself so I'd have to find a way of >> getting to process .url files, but a quick bash script could do that. >> >> Just a thought. >> >> — >> You are receiving this because you commented. >> Reply to this email directly, view it on GitHub >> <https://github.com/marcelklehr/floccus/issues/86#issuecomment-383890211>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/AJS39dSCQccF7PQXmaRSXjMOHhyt3lizks5trwUwgaJpZM4TV8wY> >> . >> > >

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@minj commented on GitHub (Apr 27, 2018):

@jlbprof would you like contributors?

I can't promise anything but I sure would love to take a look at what you have at least.

Mind pushing your changes?

@minj commented on GitHub (Apr 27, 2018): @jlbprof would you like contributors? I can't promise anything but I sure would love to take a look at what you have at least. Mind pushing your changes?

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 27, 2018):

LA-MJ, Marcel

I am currently trying to use the github javascript library:

https://github.com/sara-nl/js-webdav-client

To access my Nextcloud Webdav, I am having some form of Authentication
error about CSRF and I have a question into the Nextcloud developers
hopefully they can help me get that working.

https://help.nextcloud.com/t/csrf-with-webdav/31000

Once I have that working on both Firefox and Chrome I can then start
working on the plugin/extension itself.

So I am not quite ready, unless you know much about CSRF authentication in
Nextcloud.

I am currently waiting on a cPanel account, once that is setup I can set up
a WebDav server on that to compare against the Nextcloud one and make sure
I do not break it trying to deal with Nextcloud.

My plan at this time is to create an XBel file that I upload or download
when bookmark changes come in. Marcel has layed out a backend plugin
system so I should be able to make my webdav client do the work of moving
that file.

I have not committed this yet, but if you are interested I could create a
side github project with this code in it, as I could see a useful tool as a
simple webdav browser page.

Thanx

Julian

On Fri, Apr 27, 2018 at 2:19 PM, LA-MJ notifications@github.com wrote:

@jlbprof https://github.com/jlbprof would you like contributors?

I can't promise anything but I sure would love to take a look at what you
have at least.

Mind pushing your changes?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/floccus/issues/86#issuecomment-385068733,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJS39UZ13E5e4N4zuCtkn5OgnuA2wz93ks5ts28mgaJpZM4TV8wY
.

@jlbprof commented on GitHub (Apr 27, 2018): LA-MJ, Marcel I am currently trying to use the github javascript library: https://github.com/sara-nl/js-webdav-client To access my Nextcloud Webdav, I am having some form of Authentication error about CSRF and I have a question into the Nextcloud developers hopefully they can help me get that working. https://help.nextcloud.com/t/csrf-with-webdav/31000 Once I have that working on both Firefox and Chrome I can then start working on the plugin/extension itself. So I am not quite ready, unless you know much about CSRF authentication in Nextcloud. I am currently waiting on a cPanel account, once that is setup I can set up a WebDav server on that to compare against the Nextcloud one and make sure I do not break it trying to deal with Nextcloud. My plan at this time is to create an XBel file that I upload or download when bookmark changes come in. Marcel has layed out a backend plugin system so I should be able to make my webdav client do the work of moving that file. I have not committed this yet, but if you are interested I could create a side github project with this code in it, as I could see a useful tool as a simple webdav browser page. Thanx Julian On Fri, Apr 27, 2018 at 2:19 PM, LA-MJ <notifications@github.com> wrote: > @jlbprof <https://github.com/jlbprof> would you like contributors? > > I can't promise anything but I sure would love to take a look at what you > have at least. > > Mind pushing your changes? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/marcelklehr/floccus/issues/86#issuecomment-385068733>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AJS39UZ13E5e4N4zuCtkn5OgnuA2wz93ks5ts28mgaJpZM4TV8wY> > . >

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@minj commented on GitHub (Apr 28, 2018):

@jlbprof your problem is that you are reading docs for nextcloud-server-hosted JS and your app is external...

try webdav docs instead

All requests need to provide authentication information, either as a Basic Auth header or by passing a set of valid session cookies.

So there should be a way to set Authorization: Basic HTTP header using the lib. You haven't actually shown your JS code at all and the docs don't provide an examples (and is confusing in general)...

So sometimes is best to just follow the code...

The lib passed off your user/pw directly to XHR, which means the request is to https://[username]:[password]@[mynextcloud.tld:8008] instead of a proper Basic Auth header, presumably?

That is what I see in dev-tools anyway. There might be some hidden magic going on in there.

Try your request in a postman app or similar/with cURL first. If that works (postman builds a proper header) you will either need to build your own header or ditch this lib.

@minj commented on GitHub (Apr 28, 2018): @jlbprof your problem is that you are reading docs for **nextcloud-server**-hosted JS and your app is external... try [webdav docs](https://docs.nextcloud.com/server/12/developer_manual/client_apis/WebDAV/index.html#webdav-basics) instead All requests need to provide authentication information, either as a Basic Auth header or by passing a set of valid session cookies. So there should be a way to set `Authorization: Basic` HTTP header using the lib. You haven't actually shown your JS code at all and the docs don't provide an examples (and is confusing in general)... So sometimes is best to just follow the code... The lib passed off your user/pw directly to XHR, which means the request is to `https://[username]:[password]@[mynextcloud.tld:8008]` instead of a proper Basic Auth header, presumably? That is what I see in dev-tools anyway. There might be some hidden magic going on in there. Try your request in a postman app or similar/with cURL first. If that works (postman builds a proper header) you will either need to build your own header or ditch this lib.

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 28, 2018):

LA-MJ, Marcel

I cleaned this up a bit, and decided some help would be nice so I created.

https://github.com/jlbprof/BrowseWebDav

It now works as far as getting data from the server, I am not sure what I
did differently this time but something in cleaning up the project made it
start to work. It works in both Firefox and Chrome when connecting to my
Nextcloud WebDav point.

Please review what I have done, I will expand this out, but this will be
the basis of my backend.

Thanx for at least paying attention to my struggle :)

Julian

On Sat, Apr 28, 2018 at 2:07 AM, LA-MJ notifications@github.com wrote:

@jlbprof https://github.com/jlbprof your problem is that you are
reading docs for nextcloud-server-hosted JS and your app is external...

try webdav docs
https://docs.nextcloud.com/server/12/developer_manual/client_apis/WebDAV/index.html#webdav-basics
instead

All requests need to provide authentication information, either as a Basic Auth header or by passing a set of valid session cookies.

So there should be a way to set Authorization: Basic HTTP header using
the lib. You haven't actually shown your JS code at all and the docs don't
provide an examples (and is confusing in general)...

So sometimes is best to just follow the code...

The lib passed off your user/pw directly to XHR, which means the request
is to https://[username]:[password]@[mynextcloud.tld:8008] instead of a
proper Basic Auth header, presumably?

That is what I see in dev-tools anyway. There might be some hidden magic
going on in there.

Try your request in a postman app or similar/with cURL first. If that
works (postman builds a proper header) you will either need to build your
own header or ditch this lib.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/floccus/issues/86#issuecomment-385147498,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJS39fNeLiAquugjATFeQTGGUoLZqtXZks5ttBUtgaJpZM4TV8wY
.

@jlbprof commented on GitHub (Apr 28, 2018): LA-MJ, Marcel I cleaned this up a bit, and decided some help would be nice so I created. https://github.com/jlbprof/BrowseWebDav It now works as far as getting data from the server, I am not sure what I did differently this time but something in cleaning up the project made it start to work. It works in both Firefox and Chrome when connecting to my Nextcloud WebDav point. Please review what I have done, I will expand this out, but this will be the basis of my backend. Thanx for at least paying attention to my struggle :) Julian On Sat, Apr 28, 2018 at 2:07 AM, LA-MJ <notifications@github.com> wrote: > @jlbprof <https://github.com/jlbprof> your problem is that you are > reading docs for *nextcloud-server*-hosted JS and your app is external... > > try webdav docs > <https://docs.nextcloud.com/server/12/developer_manual/client_apis/WebDAV/index.html#webdav-basics> > instead > > All requests need to provide authentication information, either as a Basic Auth header or by passing a set of valid session cookies. > > So there should be a way to set Authorization: Basic HTTP header using > the lib. You haven't actually shown your JS code at all and the docs don't > provide an examples (and is confusing in general)... > > So sometimes is best to just follow the code... > > The lib passed off your user/pw directly to XHR, which means the request > is to https://[username]:[password]@[mynextcloud.tld:8008] instead of a > proper Basic Auth header, presumably? > > That is what I see in dev-tools anyway. There might be some hidden magic > going on in there. > > Try your request in a postman app or similar/with cURL first. If that > works (postman builds a proper header) you will either need to build your > own header or ditch this lib. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/marcelklehr/floccus/issues/86#issuecomment-385147498>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AJS39fNeLiAquugjATFeQTGGUoLZqtXZks5ttBUtgaJpZM4TV8wY> > . >

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 28, 2018):

I am also still waiting on a cPanel account to test it with WebDav, I need
to make it general enough so that it works in all WebDav scenarios.

Julian

On Sat, Apr 28, 2018 at 9:28 AM, Julian Brown julian@jlbprof.com wrote:

LA-MJ, Marcel

I cleaned this up a bit, and decided some help would be nice so I created.

https://github.com/jlbprof/BrowseWebDav

It now works as far as getting data from the server, I am not sure what I
did differently this time but something in cleaning up the project made it
start to work. It works in both Firefox and Chrome when connecting to my
Nextcloud WebDav point.

Please review what I have done, I will expand this out, but this will be
the basis of my backend.

Thanx for at least paying attention to my struggle :)

Julian

On Sat, Apr 28, 2018 at 2:07 AM, LA-MJ notifications@github.com wrote:

@jlbprof https://github.com/jlbprof your problem is that you are
reading docs for nextcloud-server-hosted JS and your app is external...

try webdav docs
https://docs.nextcloud.com/server/12/developer_manual/client_apis/WebDAV/index.html#webdav-basics
instead

All requests need to provide authentication information, either as a Basic Auth header or by passing a set of valid session cookies.

So there should be a way to set Authorization: Basic HTTP header using
the lib. You haven't actually shown your JS code at all and the docs don't
provide an examples (and is confusing in general)...

So sometimes is best to just follow the code...

The lib passed off your user/pw directly to XHR, which means the request
is to https://[username]:[password]@[mynextcloud.tld:8008] instead of a
proper Basic Auth header, presumably?

That is what I see in dev-tools anyway. There might be some hidden magic
going on in there.

Try your request in a postman app or similar/with cURL first. If that
works (postman builds a proper header) you will either need to build your
own header or ditch this lib.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/floccus/issues/86#issuecomment-385147498,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJS39fNeLiAquugjATFeQTGGUoLZqtXZks5ttBUtgaJpZM4TV8wY
.

@jlbprof commented on GitHub (Apr 28, 2018): I am also still waiting on a cPanel account to test it with WebDav, I need to make it general enough so that it works in all WebDav scenarios. Julian On Sat, Apr 28, 2018 at 9:28 AM, Julian Brown <julian@jlbprof.com> wrote: > LA-MJ, Marcel > > I cleaned this up a bit, and decided some help would be nice so I created. > > https://github.com/jlbprof/BrowseWebDav > > It now works as far as getting data from the server, I am not sure what I > did differently this time but something in cleaning up the project made it > start to work. It works in both Firefox and Chrome when connecting to my > Nextcloud WebDav point. > > Please review what I have done, I will expand this out, but this will be > the basis of my backend. > > Thanx for at least paying attention to my struggle :) > > Julian > > > On Sat, Apr 28, 2018 at 2:07 AM, LA-MJ <notifications@github.com> wrote: > >> @jlbprof <https://github.com/jlbprof> your problem is that you are >> reading docs for *nextcloud-server*-hosted JS and your app is external... >> >> try webdav docs >> <https://docs.nextcloud.com/server/12/developer_manual/client_apis/WebDAV/index.html#webdav-basics> >> instead >> >> All requests need to provide authentication information, either as a Basic Auth header or by passing a set of valid session cookies. >> >> So there should be a way to set Authorization: Basic HTTP header using >> the lib. You haven't actually shown your JS code at all and the docs don't >> provide an examples (and is confusing in general)... >> >> So sometimes is best to just follow the code... >> >> The lib passed off your user/pw directly to XHR, which means the request >> is to https://[username]:[password]@[mynextcloud.tld:8008] instead of a >> proper Basic Auth header, presumably? >> >> That is what I see in dev-tools anyway. There might be some hidden magic >> going on in there. >> >> Try your request in a postman app or similar/with cURL first. If that >> works (postman builds a proper header) you will either need to build your >> own header or ditch this lib. >> >> — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> <https://github.com/marcelklehr/floccus/issues/86#issuecomment-385147498>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/AJS39fNeLiAquugjATFeQTGGUoLZqtXZks5ttBUtgaJpZM4TV8wY> >> . >> > >

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 28, 2018):

I updated the project and it can descend the directories.

You do have to deploy this on the same domain as your webdav domain or
chrome and firefox will refuse to honor the requests.

https://github.com/jlbprof/BrowseWebDav

Julian

On Sat, Apr 28, 2018 at 9:29 AM, Julian Brown julian@jlbprof.com wrote:

I am also still waiting on a cPanel account to test it with WebDav, I need
to make it general enough so that it works in all WebDav scenarios.

Julian

On Sat, Apr 28, 2018 at 9:28 AM, Julian Brown julian@jlbprof.com wrote:

LA-MJ, Marcel

I cleaned this up a bit, and decided some help would be nice so I created.

https://github.com/jlbprof/BrowseWebDav

It now works as far as getting data from the server, I am not sure what I
did differently this time but something in cleaning up the project made it
start to work. It works in both Firefox and Chrome when connecting to my
Nextcloud WebDav point.

Please review what I have done, I will expand this out, but this will be
the basis of my backend.

Thanx for at least paying attention to my struggle :)

Julian

On Sat, Apr 28, 2018 at 2:07 AM, LA-MJ notifications@github.com wrote:

@jlbprof https://github.com/jlbprof your problem is that you are
reading docs for nextcloud-server-hosted JS and your app is
external...

try webdav docs
https://docs.nextcloud.com/server/12/developer_manual/client_apis/WebDAV/index.html#webdav-basics
instead

All requests need to provide authentication information, either as a Basic Auth header or by passing a set of valid session cookies.

So there should be a way to set Authorization: Basic HTTP header using
the lib. You haven't actually shown your JS code at all and the docs don't
provide an examples (and is confusing in general)...

So sometimes is best to just follow the code...

The lib passed off your user/pw directly to XHR, which means the request
is to https://[username]:[password]@[mynextcloud.tld:8008] instead of a
proper Basic Auth header, presumably?

That is what I see in dev-tools anyway. There might be some hidden magic
going on in there.

Try your request in a postman app or similar/with cURL first. If that
works (postman builds a proper header) you will either need to build your
own header or ditch this lib.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/floccus/issues/86#issuecomment-385147498,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJS39fNeLiAquugjATFeQTGGUoLZqtXZks5ttBUtgaJpZM4TV8wY
.

@jlbprof commented on GitHub (Apr 28, 2018): I updated the project and it can descend the directories. You do have to deploy this on the same domain as your webdav domain or chrome and firefox will refuse to honor the requests. https://github.com/jlbprof/BrowseWebDav Julian On Sat, Apr 28, 2018 at 9:29 AM, Julian Brown <julian@jlbprof.com> wrote: > I am also still waiting on a cPanel account to test it with WebDav, I need > to make it general enough so that it works in all WebDav scenarios. > > Julian > > On Sat, Apr 28, 2018 at 9:28 AM, Julian Brown <julian@jlbprof.com> wrote: > >> LA-MJ, Marcel >> >> I cleaned this up a bit, and decided some help would be nice so I created. >> >> https://github.com/jlbprof/BrowseWebDav >> >> It now works as far as getting data from the server, I am not sure what I >> did differently this time but something in cleaning up the project made it >> start to work. It works in both Firefox and Chrome when connecting to my >> Nextcloud WebDav point. >> >> Please review what I have done, I will expand this out, but this will be >> the basis of my backend. >> >> Thanx for at least paying attention to my struggle :) >> >> Julian >> >> >> On Sat, Apr 28, 2018 at 2:07 AM, LA-MJ <notifications@github.com> wrote: >> >>> @jlbprof <https://github.com/jlbprof> your problem is that you are >>> reading docs for *nextcloud-server*-hosted JS and your app is >>> external... >>> >>> try webdav docs >>> <https://docs.nextcloud.com/server/12/developer_manual/client_apis/WebDAV/index.html#webdav-basics> >>> instead >>> >>> All requests need to provide authentication information, either as a Basic Auth header or by passing a set of valid session cookies. >>> >>> So there should be a way to set Authorization: Basic HTTP header using >>> the lib. You haven't actually shown your JS code at all and the docs don't >>> provide an examples (and is confusing in general)... >>> >>> So sometimes is best to just follow the code... >>> >>> The lib passed off your user/pw directly to XHR, which means the request >>> is to https://[username]:[password]@[mynextcloud.tld:8008] instead of a >>> proper Basic Auth header, presumably? >>> >>> That is what I see in dev-tools anyway. There might be some hidden magic >>> going on in there. >>> >>> Try your request in a postman app or similar/with cURL first. If that >>> works (postman builds a proper header) you will either need to build your >>> own header or ditch this lib. >>> >>> — >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> <https://github.com/marcelklehr/floccus/issues/86#issuecomment-385147498>, >>> or mute the thread >>> <https://github.com/notifications/unsubscribe-auth/AJS39fNeLiAquugjATFeQTGGUoLZqtXZks5ttBUtgaJpZM4TV8wY> >>> . >>> >> >> >

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@minj commented on GitHub (Apr 29, 2018):

@jlbprof SOP is irrelevant

the point is to have a new back-end on floccus, not a web app, or?..

@minj commented on GitHub (Apr 29, 2018): @jlbprof SOP is irrelevant the point is to have a new back-end on floccus, not a web app, or?..

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@jlbprof commented on GitHub (Apr 29, 2018):

right this was so i could figure this out.

On Sun, Apr 29, 2018 at 1:10 AM, LA-MJ notifications@github.com wrote:

@jlbprof https://github.com/jlbprof SOP is irrelevant

the point is to have a new back-end on floccus, not a web app, or?..

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/floccus/issues/86#issuecomment-385228615,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJS39WpBwLWrS0MYpf2kFAICuM545aF_ks5ttVlugaJpZM4TV8wY
.

@jlbprof commented on GitHub (Apr 29, 2018): right this was so i could figure this out. On Sun, Apr 29, 2018 at 1:10 AM, LA-MJ <notifications@github.com> wrote: > @jlbprof <https://github.com/jlbprof> SOP is irrelevant > > the point is to have a new back-end on floccus, not a web app, or?.. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/marcelklehr/floccus/issues/86#issuecomment-385228615>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AJS39WpBwLWrS0MYpf2kFAICuM545aF_ks5ttVlugaJpZM4TV8wY> > . >

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@marcelklehr commented on GitHub (Apr 29, 2018):

Let's move dev discussions on this to the gitter channel. Feel free to join if you'd like to help -- Less spam for everyone ;)

@marcelklehr commented on GitHub (Apr 29, 2018): Let's move dev discussions on this to the [gitter channel](https://gitter.im/marcelklehr/floccus). Feel free to join if you'd like to help -- Less spam for everyone ;)

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@marcelklehr commented on GitHub (May 23, 2018):

@jlbprof has implemented the basic functionality of this. If you like, you can chime into the discussion on the file format over here. ;)

@marcelklehr commented on GitHub (May 23, 2018): @jlbprof has implemented the basic functionality of this. If you like, you can chime into the discussion on the file format [over here](https://github.com/marcelklehr/floccus/pull/105). ;)

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@marcelklehr commented on GitHub (Jul 9, 2018):

This functionality is now available in the latest beta version. See #131 for more information.

@marcelklehr commented on GitHub (Jul 9, 2018): This functionality is now available in the latest beta version. See #131 for more information.

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@Lantizia commented on GitHub (Nov 10, 2018):

FYI

The add-on description over at AMO still says you need Nextcloud or it won't work - rather than just a simple WebDAV server (at a minimum) to make it work.. https://addons.mozilla.org/en-US/firefox/addon/floccus/

The Chrome Web Store description seems fine though.

@Lantizia commented on GitHub (Nov 10, 2018): FYI The add-on description over at AMO still says you need Nextcloud or it won't work - rather than just a simple WebDAV server (at a minimum) to make it work.. https://addons.mozilla.org/en-US/firefox/addon/floccus/ The Chrome Web Store description seems fine though.

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@marcelklehr commented on GitHub (Nov 11, 2018):

Ah, thanks for the heads up. Fixed now :)

@marcelklehr commented on GitHub (Nov 11, 2018): Ah, thanks for the heads up. Fixed now :)

kerem commented

2026-02-25 22:36:06 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 21, 2023):

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions[bot] commented on GitHub (Mar 21, 2023): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Rows
Columns

[GH-ISSUE #86] Feature Request: XBEL support (or other file format) #85