nning / imgshr

Simple image gallery sharing web application.

IMGSHR

Simple image gallery sharing application. Galleries are creatable by everyone and available with a token in the URL. Everyone with the correct URL can change the gallery name, upload images and set their title. On creation, a boss token is generated, which can be used to delete the whole gallery, single pictures or make the gallery read-only later on.

You can test this at https://imgshr.space!

Features

• Galleries are shared via secret token in URL (e.g. https://imgshr.space/!Njg4NThi)
• Galleries are editable by everyone or -- when they are configured to be read-only -- only with a boss token (URL)
• Pictures can be shared with token URLs to prevent giving away a gallery's token
• EXIF data is read and shown
• Pictures can be rated
• Infinite scrolling on gallery page
• Lazy image loading
• Responsive design
• Tagging of images
• Filter by tags, date, rating
• Automatic labelling using self-hosted Convolutional Neural Network (Inception v3 model)
• GitHub login for taking track of galleries and gallery administration
• Device token authentication for galleries
• Symmetric client-side encrypted galleries with sharable secret based on libsodium (XSalsa20 for encryption, Poly1305 for authentication)
• "Responsive Images Service": Options like resize for inclusion in third-party sites
• Transparent conversion of images (to avif or webp) if browser supports these formats
• Milestones can be set by gallery and shown on images (e.g. for showing time since a certain event on photos)

Development

nvm use
npm install -g yarn
yarn
bundle
foreman start

Deployment using docker

Initial setup

Clone the source code:

git clone https://github.com/nning/imgshr.git
cd imgshr

Change the MySQL root password and the admin login credentials in .env and config/settings.yml.

Then generate a Rails secret key and paste it into .env:

./deploy.sh run web rails secret

Now start up all services (in background):

./deploy.sh up -d

The docker volumes deploy_db, deploy_redis, and deploy_storage hold the production data; make sure, you do not lose them.

The log can be followed with:

./deploy.sh logs -f

Update the code

./deploy.sh down
git pull
./deploy.sh up --build

traefik example

See examples/traefik as a starting point for a deployment with traefik and Let's Encrypt.

License

Copyright © 2014-2023 henning mueller, released under the terms of GNU AGPL 3.0.

imgshr's Issues

Wrong, random(?) key shown if visiting encrypted gallery without a key

If an encrypted gallery is visited without the right key, a random key is shown as well as a qrcode to share it which doesn't belong to the gallery. In this case all encryption informations should be omited instead.

Thumbnails for encrypted galleries

Create Thumbnails for encrypted images on the client side. This might speed up the loading of galleries as well as save users of mobile plans some of their valuable bytes.

Dependabot couldn't reach https://rails-assets.org/ as it timed out

Dependabot couldn't reach https://rails-assets.org/ as it timed out.

Is https://rails-assets.org/ accessible over the internet? If it is then this may be a transitory issue and can be ignored - Dependabot will close it on its next successful update run.

View the update logs.

Dependabot couldn't reach https://rails-assets.org/ as it timed out

Dependabot couldn't reach https://rails-assets.org/ as it timed out.

Is https://rails-assets.org/ accessible over the internet? If it is then this may be a transitory issue and can be ignored - Dependabot will close it on its next successful update run.

Client side encryption key sharing by URL

Sharing keys for client side encryption is done by attaching them to the hash part of a gallery URL. This solves the problem of including the key into URL and preventing the browser from sending it to the server while visiting it.

Following problems arise by doing so:

1. The hash part is saved in the global browser history and it seems that there is nothing that could be done about it from a programmers point of view.

2. It is very easy to leak the key for example by pasting it online, using link shorteners etc.

One way to deal with it, might be to display a warning that points out those problems, if a user tries to share the key by URL.

Possible paths to a URL with a key in it should be minimized.

In case a user visits a URL with a key in it, the hash must be removed from the URL by js immediately to minimize the risk of the user to paste a leaky url.
Also a flash msg should be shown which says something like "please clean your history" every time a URL is visited that contains a key.

Another solution could be to only "allow" key sharing by URL via a qrcode. Simply remove all ways from the site that gives the user access to a URL with a key in it. This prevents the user from pasting it to the wrong location.

The qrcode should only be shown if the user explicitly demands for it and it should be the only qrcode that is shown in this case. It is very easy to confuse the qrcode with- and without the key.

qrcode not shown

If i open the "gallery info" modal for the first time i visited a gallery, there is only shown "QR" instead of an actual qrcode. If i close the modal window and open it again, the qrcode is shown as expected. This only affects the normal qrcode for sharing a gallery link.

Set secure headers by the webserver

secure_headers is a good way to ship imgshr with some protection by default, but i think it might be more secure to set those headers outside the scope of the web application code. In case of a remote code execution it is possible for an attacker to remove or override the headers. If the headers are supplied by a webserver configuration which isn't modifiable by the application code, removal or modification can be prohibited.
The goal should be to prevent js code from being injected. Modification or removal of the headers leads to the possiblity to inject js code. So far, the only way to extract the client side encryption key from the localStorage is by injecting malicious js code.

Dependabot couldn't reach https://rails-assets.org/ due to underlying error <too many connection resets (https://rails-assets.org/specs.4.8.gz)> as it timed out

Dependabot couldn't reach https://rails-assets.org/ due to underlying error <too many connection resets (https://rails-assets.org/specs.4.8.gz)> as it timed out.

Is https://rails-assets.org/ due to underlying error <too many connection resets (https://rails-assets.org/specs.4.8.gz)> accessible over the internet? If it is then this may be a transitory issue and can be ignored - Dependabot will close it on its next successful update run.

View the update logs.

Dependabot couldn't reach https://rails-assets.org/ as it timed out

Dependabot couldn't reach https://rails-assets.org/ as it timed out.

Is https://rails-assets.org/ accessible over the internet? If it is then this may be a transitory issue and can be ignored - Dependabot will close it on its next successful update run.

View the update logs.

non docker deployment

Is it possible/is there a how to on deploying this to a shared hosting environment that does not have docker?

Dependabot couldn't reach https://rails-assets.org/ as it timed out

Dependabot couldn't reach https://rails-assets.org/ as it timed out.

Is https://rails-assets.org/ accessible over the internet? If it is then this may be a transitory issue and can be ignored - Dependabot will close it on its next successful update run.

View the update logs.