https://github.com/blog/2503-deprecation-notice-removing-anonymous-gist-creation

Will break the following features:

1. Web permissions editor (https://lpedit.lucko.me/ , /lp editor, /lp user <user> editor etc etc)
2. Verbose paste functionality (/lp verbose paste)
3. Tree view (/lp tree)
4. Debug output (/lp debug)

We have one month to figure out solutions - probably in the above order of priority.

The 2 & 3 rely specifically on Gist for it's markdown rendering. Gonna be a PITA to replicate with another service. Will probably end up requiring a custom frontend site, similar to the web editor.

4 isn't regularly used, could either be removed or moved to a different service.

The web editor is less problematic, either need to find a (relatively) reputable pastebin service with an API or make our own.

4 could be switched to hastebin or one of his 300 copies.....

Yeah, I'm less worried about that though. As I said, could probably just be removed for now.

The web editor in particular though is more of a concern, as it's quite heavily used (and a great feature imho)

Probably an idea would be that the server owner has to specify an personal access token for a valid github account. If this token only has access to gists, it should be safe I think.

or ask github for a public non rate-limited acc :)

Probably an idea would be that the server owner has to specify an personal access token for a valid github account. If this token only has access to gists, it should be safe I think.

Definitely an option, although I'd like to try avoid that if possible. Most users of the plugin don't have a GitHub account, and having to create one & setup an auth token in order for it to work is a bit of a pain.

or ask github for a public non rate-limited acc :)

Also possible, however it would require some sort of gateway (we couldn't expose the credentials for the account), and is probably against GitHub's TOS.

I think I'm going to try with Hastebin. I want to avoid hosting the content myself if possible.

Pastebin.com isn't an option - also requires an API key.

Hastebin is a very good idea, and for markdown you could use something like this on your website and just read the hastebin files remotely.

I am more to the idea of having to specify a key directly.

Another option to not expose the oAuth key is to create a small web platform which uses your format and just post to a known url and save that to a GIST, could be done quite simple (and using the same key for everyone), there is ofc. some part of it there needs to be very secure so it doesn't get abused ofc.
(This might be against the TOS, as that isn't the area I am most clear on)

If at all possible, I want to avoid hosting anything myself.

The great thing about the current solution is that it doesn't cost me anything (in hosting costs) and is completely controlled by someone else. I haven't got to worry about security, maintaining good uptime, renewing (or paying for) servers, etc etc. If for whatever reason I (as the current maintainer) disappear, existing installs of the plugin will continue to work.

An ideal solution is that we can find another pastebin service which:

1. Is reputable
2. Has a relatively lenient rate limit (GitHub's 60/hour was fine)
3. Has an API
4. Doesn't require signups or auth keys to use the API.
5. Allows CORS

GitHub met all of those - until next month where it doesn't support no. 4

This evening I've also tried with https://hastebin.com - it meets everything except no. 5. Bit of a long shot but I've submitted a PR to support CORS. I'm not sure how if it will get merged into production or not - but thought it was worth a try.

The option with GitHub oAuth could work - however I see a few issues with it.

The oAuth token would have to be stored in both the browser (as a cookie) and on the server (I guess in a config??) - this is a bit annoying - as you'd have to auth twice.

Could auth once on the server, and then transfer the auth token via the payload to the editor - however this isn't very secure / safe. In environments where two or more admins / developers share the same server, it's possible that one users key could be leaked to the other user - and would therefore grant them access to the other users entire collection of gists. I don't think that's an acceptable security risk to take. Could isolate it to a specific user - but would still be stored in a config.

A final option is to look for an organisation that would sponsor the project with hosting. If that removes me as a person from the equation then it could work out. I guess it would have to be a server hosting firm or something like that. Needs to be someone who's gonna stick around for a while.

I know that's all quite a lot to read - but I'm just kinda dumping ideas at this point. Keep the ideas / suggestions coming! :)

A final option is to look for an organisation that would sponsor the project with hosting

Perhaps @md-5 could via SpigotMC. They already run an API. Might also be later used for other plugin devs for built in reporting instead of the mess that I've seen on some other plugin discussion pages. (aka wall of text dumps)

md_5 already has a pastebin, but I don't want to start bothering people outside of the project. (and don't think it was really appropriate to tag him in this)

Another possible option is to use Hastebin + a CORS proxy in the web client.
https://cors-anywhere.herokuapp.com/

Personally I'd say that we should try to get an unlimited API token and get in contact with them regarding how to properly deliver it in the jars and the web clients.

Pretty much impossible to do it without leaking the token in some way.

I tried the cors-anywhere thing - was super slow - so that's not gonna work.

I think the way forward is for me to just host the content myself - and make sure it's easy for people to host their own mirrors of it.

I mean it must be possible to do it without leaking it. We can't be the first repo having this issue...

Most apps using the API just get the user to authenticate - that's possible in most uses, but not for us. (as explained above)

However, it is not possible to register one "shared" LuckPerms app token for everyone to share, as you should not leak the keys.

Personally I'd say that we should try to get an unlimited API token and get in contact with them regarding how to properly deliver it in the jars and the web clients.

Malicious users could easily find the key and use it for other things. (malicious purposes)

There's a rate limit for a reason. Even members of the developer program have a rate limit.

What is the current plan? Host it all on your own? For that, it would be good to have something like mirrors (could be hosted by everyone and "certified" by you for example) for different regions and continents.

For now yes.

Once finished, I'll write some sort of self hosting guide so people can setup mirrors. (I don't know about making them official though.)

You could check if a hosted website is reputable and add it to a list in the config with the time zone or something similar of their location and pick the "best" of them for each server.
Probably a little bit over the top... 😄
#Edit: Another way would be to use SRV-Records to spread the usage and prevent downtime of the service.

IMO, i would recommend hastebin as an alternative to gist. There is APIs to post to hastebin and get the URL, what you could do is convert it to the command

Like https://hastebin.com/raw/hupayaxoli would be used as /lp applyedits hupayaxoli

This evening I've also tried with https://hastebin.com - it meets everything except no. 5. Bit of a long shot but I've submitted a PR to support CORS. I'm not sure how if it will get merged into production or not - but thought it was worth a try.

Vote for the PR, maybe can help :)
toptal/haste-server#204

I've made some good progress with this issue.

Based on the discussion above (thanks for everyone's ideas) - I think the best course of action is for the project (me) to host a simplified upload service for LuckPerms web data. We can always look at moving this elsewhere in the future.

I wrote this last night - super simple but should do what we need it to.
https://github.com/lucko/bytebin
Has a post API to submit data, returns an id of the resultant "paste". Browsing to /<id> will return the raw content. Uploads (currently) expire after 1 day.

A new version of the web editor is live at https://luckperms.github.io/editor/ - it's using the new upload service for data transfer.

Instead of implementing a site to just render markdown produced by the plugin (to replace Gist's functionality), I think now's a good time to move the other web stuff (verbose & treeview) over to nicer sites.

There's an early prototype for verbose here. https://luckperms.github.io/verbose/

The plugin is updated for these changes, but I haven't merged them into master just yet.
https://github.com/lucko/LuckPerms/tree/web

Still need to work on porting the tree view stuff. Should be fun. :)

Maybe if the load on your server ever become too high you can integrate a small webserver in the plugin itself.

Wow! You've made an amazing progress.

Okay, everything is merged now!

New sites are live at

• https://luckperms.github.io/editor/
• https://luckperms.github.io/verbose/
• https://luckperms.github.io/treeview/

The debug command posts to https://hastebin.com/

Data payloads are transferred via https://bytebin.lucko.me/ https://github.com/lucko/bytebin

I'll push an update to Spigot / Sponge in the next week or so to hopefully give people enough time to update before the anon Gist API stops working.

Perhaps when those updates are posted, a notice can be added to the old site at https://lpedit.lucko.me

Thanks for all the comments and ideas 😃

p.s. if there are any web devs lurking here, I'd appreciate any improvements/contributions to the new sites https://github.com/lucko/LuckPermsWeb

Maybe if the load on your server ever become too high you can integrate a small webserver in the plugin itself.

I doubt it will ever be an issue.