Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is exposing customized endpoints for organizations within scope of this project? #415

Open
sargunv opened this issue Feb 26, 2021 · 1 comment

Comments

@sargunv
Copy link

sargunv commented Feb 26, 2021

Hey, I'm an ex-Bunny user, and I've been wanting to set up something similar to Bunny for both myself and for the team I work with now. Wondering if adding the ability to expose a custom endpoint for an organization is within scope for this project, or if I should look into self-hosting a customized fork instead.

@taneliang
Copy link
Owner

Hey, thanks for reaching out. Really cool that you're considering using this :D

Yeah, I think for now it'll be easiest to self host a fork so that you can add and update your handlers without going through me. It should be really easy to deploy this, but lmk if you run into any issues.

However, I've also started using Neh at work and I think it'll be a lot more useful if we had more custom handlers for the company that weren't also exposed to the general public.

To support that use case, I have been thinking of building in some sort of federation of multiple self-hosted Neh instances. For example, the "iron" handler I've built for my company could just 302 redirect to a company-hosted Neh instance, which could be built and secured as the company sees fit without adding too much complexity to Neh itself.

Having said that, this is a longer term idea and there's definitely no timeline for building this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants