Didn't see any straightforward way to do this, it's possible I missed something.

Instead of using an IDP, load users from a htpasswd, plain text, or json list of usernames and (optionally hashed) passwords

Just a very basic issue. Should be a quick fix. I don't have extensive knowledge of andesite internals yet so bare with me if I'm mistaken about anything.

Expected Behavior

If a user with no permissions attempt to login, and I then boot andesite with the --admin parameter set to that existing user id, I should then be able to login as that user and have admin privileges.

Problematic Behavior

The above user will still lack the ability to view the directory at all despite having admin permissions. This is inconsistent behavior to what happens when adding a user who has not attempted to login yet, as the added user can instantly view and manage the andesite instance. This can cause potential issues when configuring for the first time.

How to Reproduce

Visit an andesite instance and attempt to login with an unregistered user. Once denied, reboot the server with the --admin parameter set to that user's ID. Attempting the login again will still deny access.

Suggested Fixes

Assuming that the admin permission is being set correctly in both cases:

1. allow all admin users to view the directory regardless of other permissions OR
2. explicitly give existing users who are set to admin viewing permissions when the --admin parameter is processed

Feedback on the format is appreciated.

As of commit 0685244, the theme configuration is handled via the config.json file. I propose that a theme can be configured by simply referring to its Git repository, like so:

config.json

{
	"theme": [
		"dark",
		"github.com/nektro/OfficialDarkTheme",
		"custom.url/KNOXDEV/UnofficialButStillPrettyCoolTheme.git"
	]
}

The first entry, dark, is a built-in theme that internally translates to a git repository.
The second entry is a GitHub URL to the repository that contains the theme to be downloaded directly.
The third entry isn't a GitHub URL, but it IS a valid git repository, and will be interpreted the same.

Andesite can then be responsible for reading the configuration at runtime, downloading the theme from the provided Git repository (with a very specific structure), placing the files into the .andesite/theme-name/ folder, and serving from there like previously.

Having the ability to install themes like this makes both configuration and 3rd party theme creation very easy.

Give users the ability to generate a code that they can pass as a custom header using tools like curl or rclone and not have to deal with exporting their cookies and importing them into their CLI tool of choice.

So,
/files/archive/YouTube Channels/PewDiePie/

Could also potentially be accessed from
/open/e189454544eca1cee27434f58bd18f45/archive/YouTube Channels/PewDiePie/
or other code where e189454544eca1cee27434f58bd18f45 is generated from /admin

When users are only referenced by a snowflake/email, it would make recognizing users a lot easier if you could add a small note and arbitrary text next to their name

sorry if I'm missing something really obvious, I don't have any previous experience with go and I'm trying to run this :)

I tried it in two different servers (debian 9 and ubuntu 19.10) with the same results..

• got the latest version of go
• go get -u github.com/nektro/andesite

I see it gets and auto compiles to ~/go/bin/andesite so I tried to run this first and the result is

2019-11-27 22:33:04: Initializing Andesite...
2019-11-27 22:33:04: Reading configuration from /home/rafa/.config/andesite/config.json
2019-11-27 22:33:04: statik/fs: no zip data registered

then I went to ~/go/src/github.com/nektro/andesite

• go build && ./andesite
  (same result)

last thing I tried was changing my config.json to

{
"version": 2,
"root": "/home/rafa",
"public": "/home/rafa/public",
"port": 8000
}

which made no difference

any help would be appreciated, thank you

Title says most of it. If we're going to create a more involved, dynamic frontend, we'll possibly need to overlap a new build system that can process these new systems in addition to go build, which we already use. In order to not directly affect the existing process, to create a single point of interaction for the developer and simplify the build process, i propose using the incredible widespread make system.

Example usage

# to build (will handle packr and the rest in one step)
make
# to build the front end
make frontend
# to run the result
make run
# to install as a service
make install

As you can see, this stands to drastically simplify the existing build process, it will integrate seamlessly with IDEs, and is very simple to maintain/extend to our future build process which may be more complex.

Make is a guaranteed package on 90% of Linux systems, and Windows developers are already required to have GCC installed to compile this project, which in most Windows-based GCC distributions already come with make.

Let me know if making this change to the build system will cause any foreseeable issues.

https://github.com/valyala/fasthttp

Trying to get files using the generated command fails ex

rclone copy --http-url="http://xxxxxx.com/files/folder/" :http: ./ -P --user-agent "AndesiteUser/xxxxxxxxxx"

adding -vv, we can see its because by default it sends a HEAD request to get info about each file, show total % downloaded, etc

one option for now is adding --http-no-head but it causes some problems https://rclone.org/http/#http-no-head

Should return 404, or similar. So that outside viewers do not know the path exists.

Currently you can only access the files inside a public share, and not the folders inside one as well.

Problem: Redirects to https://example.com//

Files:

~/.config/andesite/config.json

{
    "root": "/var/www/[REDACTED]/public/private",
    "base": "/private/",
    "port": 8021,
    "auth": "discord",
    "discord": {
        "id": "[REDACTED]",
        "secret": "[REDACTED]"
    }
}

/etc/nginx/sites-available/[REDACTED].conf

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        server_name [REDACTED];
        root /var/www/[REDACTED]/public;

        # SSL
        ssl_certificate /etc/letsencrypt/live/[REDACTED]/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/[REDACTED]/privkey.pem;
        ssl_trusted_certificate /etc/letsencrypt/live/[REDACTED]/chain.pem;

        # logging
        access_log /var/log/nginx/[REDACTED].access.log;
        error_log /var/log/nginx/[REDACTED].error.log warn;

        # index.php
        index index.php;

        # index.php fallback
        location / {
                try_files $uri $uri/ /index.php?$query_string;
        }

        # handle .php
        location ~ \.php$ {
                include nginxconfig.io/php_fastcgi.conf;
        }

        location /private/ {
                proxy_pass http://localhost:8021/;
                proxy_set_header Host $host;
        }

        include nginxconfig.io/general.conf;
}

# subdomains redirect
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        server_name *.[REDACTED];

        # SSL
        ssl_certificate /etc/letsencrypt/live/[REDACTED]/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/[REDACTED]/privkey.pem;
        ssl_trusted_certificate /etc/letsencrypt/live/[REDACTED]/chain.pem;

        return 301 https://[REDACTED]$request_uri;
}

# HTTP redirect
server {
        listen 80;
        listen [::]:80;

        server_name .[REDACTED];

        include nginxconfig.io/letsencrypt.conf;

        location / {
                return 301 https://[REDACTED]$request_uri;
        }
}

As opposed to doing, Welcome, 224618666111533057

https://snapcraft.io/

As long as this is a project for self-hosted open directories, we might as well add support for self-hosted github-like services like Gitea: https://docs.gitea.io/en-us/oauth2-provider/

Shouldn't require anything complex on top of what the Github OAuth already does other than the ability to configure the Gitea instance hostname in config.json, which is arguably what the Github configuration should already have since self-hosted Github Enterprise is a thing.

I think requiring CLI arguments to function properly is not an ideal configuration strategy for what essentially amounts to a service. I propose the following:

1. Eliminate all command line arguments except one: --config that will allow you to declare the location of config.json dynamically
2. If the config argument above is not passed, fall back to some POSIX-y default, like ~/.andesite/config.json
3. Move all previous command line settings into config.json

This strategy is very typical for applications of this nature.

PS C:\Users\CatTh\Development\andesite> .\andesite-v2019.07.23-3f9c6b9-windows-amd64.exe
[2019-07-24 19:43:21] Initializing Andesite...
[2019-07-24 19:43:21] Reading configuration info from C:\Users\CatTh/.config/andesite/config.json
[2019-07-24 19:43:21] Sharing private files from X:\thrash
[2019-07-24 19:43:21] Sharing public files from X:\
Error
"Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub": []
goroutine 1 [running]:
runtime/debug.Stack(0xc042004018, 0xc04207f3b8, 0x1)
        /usr/local/go/src/runtime/debug/stack.go:24 +0xae
runtime/debug.PrintStack()
        /usr/local/go/src/runtime/debug/stack.go:16 +0x29
main.checkErr(0xa4c0c0, 0xc04204b970, 0x0, 0x0, 0x0)
        /go/src/github.com/nektro/andesite/main.go:316 +0x202
main.main()
        /go/src/github.com/nektro/andesite/main.go:140 +0x10cd
[2019-07-24 19:43:21] [error] "Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub": []
goroutine 1 [running]:
runtime/debug.Stack(0xc04207f178, 0x1, 0x1)
        /usr/local/go/src/runtime/debug/stack.go:24 +0xae
runtime/debug.PrintStack()
        /usr/local/go/src/runtime/debug/stack.go:16 +0x29
github.com/nektro/go-util/util.CheckErr(0xa4c0c0, 0xc04204b970, 0x0, 0x0, 0x0)
        /go/src/github.com/nektro/go-util/util/util.go:178 +0x192
github.com/nektro/go-util/sqlite.(*DB).Query(0xc0422144f0, 0x0, 0xc0421f0a00, 0x43, 0x1)
        /go/src/github.com/nektro/go-util/sqlite/sqlite.go:100 +0x141
github.com/nektro/go-util/sqlite.(*DB).DoesTableExist(0xc0422144f0, 0x85a410, 0x5, 0x400)
        /go/src/github.com/nektro/go-util/sqlite/sqlite.go:87 +0xde
github.com/nektro/go-util/sqlite.(*DB).CreateTable(0xc0422144f0, 0x85a410, 0x5, 0xc04207fa18, 0x2, 0x2, 0xc04207fcc8, 0x3, 0x3)
        /go/src/github.com/nektro/go-util/sqlite/sqlite.go:60 +0x64
main.main()
        /go/src/github.com/nektro/andesite/main.go:142 +0x12c9
PS C:\Users\CatTh\Development\andesite>

OS: Windows 10 1903 Professional for Workstations x64
Terminal: PowerShell 5.1

With a --theme value of "./blue/" for example. Expansion of #37.

Running Andesite on a non-typical port, just as 8000 (the unconfigured default), will cause issues in the redirect url when attempting to log into Discord.

As we can see, the redirect url is being sent to Discord correctly:

...but Discord doesn't like port numbers in its redirect url:

Not sure what to do about this, since its mostly Discord's fault. Figured I'd better document the issue regardless of if we plan to fix it.

Via: https://discordapp.com/developers/docs/resources/guild#get-guild-member
and https://discordapp.com/developers/docs/resources/guild#guild-member-object

🐱‍💻 dark-theme branch

• google
• microsoft
• facebook
• reddit
• twitter
• github

As above or add setup process on first time web page load/when no config found.
This would ease setting up Andesite for non-technical people.

This is to be able to use rclone serve and other programs that already create ODs