[Beta Test] Some Findings - Joplin Server / Client 2.0.1

Joplin Desktop 2.0.1 Windows 10 x64 (VM)
Joplin Server 2.0.1-beta RaspiOS ARMx64 (florider89/joplin-server)
Database: SQLite

I realise that I am not using the official docker image. If you feel that any errors I am seeing could be due to this setup, please advise and I will leave it to others to test on more orthodox equipment!!

Observations:

Note sharing worked. Any selected note, when shared, can be viewed as a web page. I appreciate this is very new and being developed but notes are currently shared without access control. Admittedly guessing a url would be very difficult given the size and complexity of the identifier (I think this has been mentioned somewhere on the forum already). However there does not appear to yet be a way to "unshare". Is a share link permanently live?

I ask as a shared note is not fixed in time. If a shared note is later updated, those updates are shown. This could be a good thing (the note is up to date) or a bad thing (you have forgotten that you have actually shared the note or who you shared it with and you really did not want them to see that update!). Which leads on to ...

There does not appear to be any indicator yet in the client that a note has been shared. Also, if the same note is shared again a new url is created rather than the existing one reused. This could add up to a lot of shares quite quickly. All the share urls seem to remain live.

Bugs?

If the option on the server to delete all user data is used (items > delete all) , all data is automatically deleted from the client even though failsafe is set on the client.

If a note has been shared and later the server option to delete all user data is used (items > delete all) , an error of "no id provided" appears (see below) and the user is logged out. Logging back in shows that the user data is still present. Selecting the delete option again gives the error again and the user is logged out again. I have used the option to delete the data on the server several times when testing and I have only got this error the first time I tried to delete all data after a note had been shared.

2021-05-15 22_26_03

2 Likes

System: Arch Linux
Joplin Desktop 2.0.1
Joplin Server 2.0.1-beta (official docker image)
Database: Postgresql

If I create a new note and make it shareable, the share works as expected. However, if I delete the note and try to sync afterwards, it throws out error saying "no id provided"

image

1 Like

Thanks for the detailed report, much appreciated!

Note sharing worked. Any selected note, when shared, can be viewed as a web page. I appreciate this is very new and being developed but notes are currently shared without access control.

I don't expect this to ever be any different. I feel supporting a password wouldn't make sense because the password is the share key (the URL ID). I guess if someone requires extra security they can always send a part of the URL via one channel and the second part via another one. Share keys are a 32 characters nano-id, and it would apparently take "more than 1 quadrillion years needed, in order to have a 1% probability of at least one collision", so that sounds secure enough.

However there does not appear to yet be a way to "unshare". Is a share link permanently live?

Yes this is missing, and I'm planning to add this soon.

There does not appear to be any indicator yet in the client that a note has been shared.

I'm planning to add this to. I think I'll add a place where you'll be able to see all your share notes and links so that you can easily unshare them if needed.

Also, if the same note is shared again a new url is created rather than the existing one reused.

The reasoning was that you might want to share a note with user 1, then later on the same note with user 2. After some times, you decide to unshare the note from user 2 but you still want user 1 to have access to it. By creating new share links every time you basically have more control over who can access the note or not. But maybe I'm overthinking it, I'm not sure yet.

If the option on the server to delete all user data is used (items > delete all) , all data is automatically deleted from the client even though failsafe is set on the client.

Failsafe is not active for Joplin Server and I don't think it will be since failsafe requires knowing in advance how many items are going to be deleted. By Joplin Server supports delta sync so we can't know in advance what changes will be apply, at least not without a performance hit. Probably I'm remove this "Delete all" button at some point, as it's there mostly for testing.

If a note has been shared and later the server option to delete all user data is used (items > delete all) , an error of "no id provided" appears (see below) and the user is logged out.

Indeed it looks like the bug found by @thelazyoxymoron related to share, that will be fixed in the next version.

1 Like

I would like to add that for me (also same docker image from florider), when I go to the "items" tab in the web interface, I get this error message. Unfortunately I don't really know what it means....

2 Likes

Yes this is already fixed and will be in the next release.

2 Likes

I thought that the points raised would likely be on your to-do list!

Ideally with a note field so you can record who has been given the share? Or a note field available as part of the share creation?

That makes perfect sense to me. If someone no longer needs the note then access can be removed just for them (as long as you know what share they have been given), rather than removed for everyone and a new link sent to those that continue to require it. Speaking of "overthinking", a time-out option to auto expire links may be handy to have at some point. (saves manual house-keeping).

Being able to clear out the server is also very useful for starting over again, such as after E2EE problems involving multiple keys. Unlike Nextcloud, Dropbox et al., which have their own file managers, there would be no way to purge the account.

Thanks for all the work you have put into this. I am amazed at how far this project has progressed since I discovered it a few years ago.

For now, I've actually gone back to only one link per note. Multiple links per note would indeed require the kind of UI you mention but I prefer to keep it simple for now, and make this kind of improvements in future versions.

1 Like

Docker images (arm64):

  • Joplin Server: florider89/joplin-server:2.0.1-beta
  • Database: postgres:13.3

Joplin Desktop: 2.0.1 prerelease (running on KDE Neon 20.04)


I've noticed many of the findings mentioned above. Here's another:

If you try to share a notebook with a user that does not exist, you get the message: User not found. This makes sense, but then the notebook has an indicator that it is being shared.

image

Clicking Unshare does nothing.

The only way I've found to remove this share indicator is to first share with someone who DOES exist, and then click on Unshare.

Not a big deal, but figured I would report it because I'm sure this is not the way it is intended to work.

Yes it's expected behaviour actually, although maybe that could be improved. When you share a notebook, first it turns the notebook into a shared one, and only then it can send the invitation to the user. If the user doesn't exist, it fails, but the notebook is still a shared one (although only you have access).

The unsharing issue seems to be a bug though.

I have not been using the official server image for testing and thought I should. I have been having problems...

I am very new to Docker so I could be making some fundamental error. Please don't be too brutal...

What I have noticed is that if I try to run Joplin server (in SQLite "mode") on an x86_64 VM (Ubuntu 20.04) using an .env file which only contains entries for APP_BASE_URL and APP_PORT and the command:

docker run --env-file .env -p 22300:22300 joplin/server:2.0.1-beta

I get a what appears to be ShareService and SQLite errors reported by Docker as Joplin Server is set up after the image download.

The errors start

2021-05-17 19:30:45: [error] ShareService: Could not update share items: Error: select `id`, `name`, `mime_type`, `updated_time`, `created_time`, `content_size`, `jop_id`, `jop_parent_id`, `jop_share_id`, `jop_type`, `jop_encryption_applied` from `items` where `id` in ('UuUDw004TMrqqZWc1qWnleGt1fEVHyfY',...
    at /home/joplin/packages/server/dist/models/BaseModel.js:8:71
    at new Promise (<anonymous>) {
  errno: 1,
  code: 'SQLITE_ERROR',
  originalStack: "Error: select `id`, `name`, `mime_type`, `updated_time`, `created_time`, `content_size`, `jop_id`, `jop_parent_id`, `jop_share_id`, `jop_type`, `jop_encryption_applied` from `items` where `id` in ('UuUDw004TMrqqZWc1qWnleGt1fEVHyfY',...

Joplin server 2.0.1-beta does run and the web interface can be accessed. However when following the prompt to change the admin password the url is shown as a localhost address despite the setting in the .env file.

Interestingly admin@localhost appears to contain note data and there is also a user2@example.com.

Joplin Desktop client 2.0.1 cannot connect due to SQLite errors.

If I use the same .env file and run the same command but using @florider's version:

docker run --env-file .env -p 22300:22300 florider89/joplin-server:2.0.1-beta

I do not get the errors, "Admin"'s account does not contain data and there is no "User Two" account.

Joplin Desktop client 2.0.1 connects and syncs.

I have deleted the joplin/server:2.0.1-beta container several times and re-run the docker run command but it always errors. I have also deleted the docker container and the image and re-downloaded it and it still errors at the same point.

Is something odd going on here with the Joplin Server image on Docker Hub or should I just delete this post and leave Docker alone? :slight_smile:

How does the end look like? As this is where it should tell where is the mistake in the SQL statement.

Admin should not have any data unless you've used this account to sync. And user2@example.com is created with a debug action, when you call curl --data '{"action": "createTestUsers"}' http://localhost:22300/api/debug, but you'd have to call it explicitly so it's weird the user exists. Are you sure it's not left over data from earlier tests?

@laurent, thanks for the reply.

I just took the VM back to pre-docker. I fully updated, installed docker (using their script), set up an nginx reverse proxy, including the required certs and ran the docker run command.

Each error ends with SQLITE_ERROR: no such column: jop_share_id

and I have an Admin user with data and a User Two.

I cannot see where any old data could come from but I am certainly not ruling out user error as others must be using the 2.0.1 server image in the "SQLite Mode".

It's getting late now. Tomorrow I will likely build a new server from scratch just to rule out "contamination" (and I'll have to learn a bit about Docker rather than just cut and paste other people's stuff!).

Built a new Ubuntu server and only nginx and Docker have been installed.Same happens: SQLite error, an extra user and an admin account with data in it.... unless Docker is downloading an image with a SQLite database with data already in it or some debugging / testing script is being triggered, I cannot see where this is coming from.

The odd thing is that if I use the same command on the same machine where I have tried to run the official build, but substitute @florider's image file, it works.

I am confused and giving up until my headache goes away!!

Ok thanks for checking. It's a mystery to me how the database can be populated by default, but I'll try the Docker image directly with SQLite to see if I can replicate it.

Upgrade and (manual) migration to 2.0x worked without any issues. (Server: Debian 10.9, Client: Fedora 33 AppImage)

Besides all the other issues/suggestions reported in this thread, I'll add a few;

  1. (auto) Dark mode or theme selection
  2. Use browser time to change/set the timezone for 'Last updated: xxxx'
  3. Use note title as tab title (currently it shows the note url)
  4. The branding icon (Joplin) redirects to /home which is forbidden, rightly so, for non logged in users. I suggest to redirect it to /login OR have /home redirect to /login if user is not logged in OR have a new login link in the usual top-right corner.