Weird behaviour when inputing passwords with a trailing backslash

[c13mn14k]

Describe the bug / to reproduce

(Case 1)

Frontend logic removes (at least) trailing backslashes from a password input when accessing a protected share.
I had a quick look, and it's probably due to this:

photoview/ui/src/helpers/authentication.ts

Lines 20 to 25 in 8cdc4cd

	export function getSharePassword(shareToken: string) {
	const match = document.cookie.match(
	`share-token-pw-${shareToken}=([\\d\\w]+)`
	)
	return match && match[1]
	}

The resultant behavior is:

1. Create a share with a password (let's say password is only [a-zA-Z]+)
2. Access the share as an unathenticated user
3. Input the password with a trailing backslash (or backslashes)
4. You are authenticated and share is shown

Expected behavior:
user is not authenticated and not authorized to the share.

(Case 2)

I also checked the behavior when the password itself had a trailing backslash. For example, when password is a\, using a password that matches a\\* does not authorize to the share, sometimes throwing an internal server error. When the share password is simply \, then inputing \ results in:

2023/09/06 23:50:04 Did not find auth-token cookie
runtime error: invalid memory address or nil pointer dereference

goroutine 2257323 [running]:
runtime/debug.Stack()
...

also

Sometimes (??) when inputing password+trailing slashes I'm authorized to the share, but the image doesn't display (link to the image is unauthorized). In that case though, there are exif settings visible, so there is still info leak:

Expected behavior:
just normal password stuff

Your environment:
Nothing too useful, Docker-compose, Ubuntu server, postgres

version: undefined?
I pull from viktorstrate/photoview:master, 4f1126b4d5b3

[kkovaletp]

@jordy2254, as you're working on user management epic, this issue might be interesting for you