Well, that's okay; you're young. There are better and more topical jokes in your future, and it will serve you well in making them to have encountered this particular, extremely stale and suspiciously stained, cookie. Just be careful you don't take too big a bite!
Reverse proxy itself will do barely any defense, what you need in combination is an authgate (authentik, authelia), and here we are moving from "simple reverse proxy" to fun weekend activity and then some getting it to work as expected. + it kills the app auth flow, so only web interface is suitable for this.
You can use a reverse proxy and still have working app auth, I have set this up via Authelia with the OIDC Jellyfin plugin.
However:
- This is EVEN MORE complex than "just" a reverse proxy.
- I'm not really sure it wins much security, because...
- at least I'm not relying on Jellyfin's built-in auth but I'm now relying on its/the plugin's OIDC implementation to not be completely broken.
- attackers can still access unauthenticated endpoints.
Overall I really wish I could just do dumb proxy auth which would solve all these issues. But I dunno how that would work with authing from random clients like Wii (and more importantly for me, WebOS).
With a reverse proxy, I don't see how this would work. The whole way the reverse proxy works is you use a subdomain name ("jellyfin.yourdomain.org") to access Jellyfin, rather than some other service on your server. The reverse proxy sees the subdomain name that was used in the HTTP request, and routes the traffic based on that. Scanning only the IP address and port won't get attackers to Jellyfin; they need to know the subdomain name as well.
The only tricky part here would be to make sure you’re doing a wildcard certificate, so that your subdomain doesn’t appear in Certificate Transparency logs.
If you expose Jellyfin on 443, have HTTPS properly set up (which Caddy handles automatically), your admin password is not pswd1234 (or you straight up disable remote admin logins), and use a cheap .com domain rather than your IP--what is the actual attack surface in that case?
As far as I can remember that is more or less what is usually suggested by Jellyfin's devs, and I have yet to see something that convinces me about its inadequacy.
The absolute worst thing I can see in there is that an third party who somehow managed to get a link to one of your library items (either directly from you or from one of your users--or by spending the next decade bruteforcing it I guess) could stream said item:
https://github.com/jellyfin/jellyfin/issues/5415#issuecommen...
Everything else looks to me like unimportant issues, that would provide someone who's already logged in as a user minor details about your server.
Unless I am misunderstanding the discussion on GitHub, the attacker would still need to know the exact path where the file is saved, and the name of the file itself. Even then, all they can do is download the file from your device--which they could just torrent themselves for a fraction of the effort.
Yea its pretty bad, there are pages of non-fixed confirmed exploits, you really shouldnt let it face the net.
VPN is one solution, and actually the only real solution for app-based jellyfin (TV, phone apps) I found so far.
Another is to host Jellyfin behind reverse proxy, and have a completely independent authgatein front of it (authentik, authelia). Jellyfin even supports LDAP (trough plugin), so you dont have to login twice per visit. The downside is only web interface can be hidden this way, as apps will break expecting jellyfin auth page and finding something else.
I heard that we often get cold/flu/sore throat when we get too cold outside, because the inside of our orifices is kept at a certain temperature to kill those bacteria/viruses. When we get too cold, we are unable to kill them fast enough, and get overrun. Staying in 70-100°C air for prolonged time must also heatshock those parts of our bodies, so I guess we kinda sterilize it that way.
I am running opus to make changes to my code then running the code. I am genuinely curious how we are having such disparate experiences here. And at this point, IMO you're in too deep not to share...
Genuinely wondering if you're running gastown or some other crazy mixture of agents pretending they're an AI startup. I get by with a developer agent and a reviewer agent ping ponging off each other encouraged to be rude, crude, and socially unacceptable about it.
Actually its just one opus aimed at a codebase with one goal, and instruction to spawn 2 subagents: one worker, that comes up with implementation plan, one validator that validates the proposed plan against my guardrails, and then return back to subagent1 to implement this, where the second subagent again tests the implementation.
One loop of this can take 20-60 min, and eat 2-5% of my week limit. I have to actively slow myself down to not burn trough more than 15-20% of my weekly limit in a day (as I also like to work on it on weekends)
Sadly I cant share the actual problem I am working on as its not my secret to disclose, but its nothing "crazy", and I am so surprised others dont have similar experience.
Very similar to what I am doing. How big is the codebase? My biggest was about 250K LOC and the usual is about 10K LOC. I am really curious about figuring this out because I'm genuinely puzzled.
My code base is two monorepos 10M+ lines. I have the same experience as you - run 3-6 agents with remote devcontainers and tmux and rarely break the 75% usage, never had the weekly limit stop me.
My observations are these things impact both quality and token consumption a lot.
- Architecture matters really- how messy code is and how poorly things are organized makes a big difference
- how context window is managed especially now with default 1M window.
- How many MCP servers are used. MCP burn a lot, CLI tools are easy , quicker and good ones don't even need any additional harness like skills etc, just prompt to suggest using them.
- Using the right tool matters a lot
- What can be done with traditional deterministic tools have to be done that way with agent controlling (or even building) the tool not doing the tool's work with tokens.
- for large refactors codemod tools AST parsers etc are better than having the agent parse and modify every module/file or inefficiently navigate the codebase with grep and sed.
- How much prep work/planning is put in before the agents starts writing code. Earlier corrections are cheaper than later after code is generated
Typically my starting prompts for the plan phase are 1-2 pages worth and take 30-60m to even put in the cli text box. With that, first I would generate detailed ADRs, documentation and breakdown issues in the ticketing system using the agent, review and correct the plan several times before attempting to have a single line written.
---
It is no different as we would do with a human, typing the lines of code was always easy part once you know what you want exactly.
It feels faster to bypass the thinking phase and offload to agent entirely to either stumble around and getting low res feedback or worse just wing it, either way is just adding a lot of debt and things slow down quickly .
reply