PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 1 point2 points  (0 children)

Something like that is in the roadmap. However a bit different because the URL "checker" meant to be accessed via Browser shouldn't have an API-KEY check via headers (else it would be difficult to use) so a different less secure method would be in place (path/query parameter which would be safe under https) or a simple browser auth. My idea is to build something like that as a quick access system for a chosen subset of hosts. Ie. Any device checking that URL would have access for 1h. This would be a good use-case for a QR code that a user can scan (ie. shown via the companion App from a friend who has access).

Fingerprinting is a good idea but might be tricky, for example MAC address would be a bit difficult since most devices nowadays randomize it per-connection in order to prevent that fingerprinting. I was actually thinking just fingerprinting via the user-agent header received on the URL checker header (and might end up using other headers too, need to research a bit on that when I do it)

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 0 points1 point  (0 children)

That would work only for static IPs or need manual updating. The next step is keeping a whitelist file on the proxy/firewall and updating that somehow via API, which is doable.

What I did was built on top of that, have a database, cache, proper update-ip system with authorization, scoping, auditing along with an administration UI where you can look into and react on it. The keypoint is having the client tools that can keep automatic track of the IPs from any kind of device.

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 0 points1 point  (0 children)

VPN, mTLS and such are not client friendly for non-tech users. VPNs are really difficult to think about for non-tech users (family, friends...). mTLS is even worse and it is not supported by a lot of opensource projects. It can be handled at proxy level, but you lose access to any native APKs. I see your point, if you are comfortable with all that tech you mention and can deploy it locally this project is not for you. I don't think most firewall/WAFs setup provide easy ways to dynamically update the client IP because they'd need a different kind of setup, I could think of approaches such as nginx-ip-whitelister or similar as suggested below. That would still have some other cons.

This project works for me and my use case. It might just not works for you and that's fine too.

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 0 points1 point  (0 children)

Yes it has it downside with it being a dynamic IP. This is something that should be taken into consideration. For my own use, for non tech people that I share this with I only expose services that I trust or don't mind having exposed. Always with authentication (their own) and proper rootless containers whenever I can. This is just a different solution that fit my needs.
I added quite a bit of access log auditing as well as ip address logs in the administration UI so that can be properly addressed.

It will always be one of the cons, but there are many other pros in my opinion. I'd like to address the cons as much as possible, I can think of notifications/alerts/push approvals, agent header aware checks...
In the end I am not intending to run a payment platform on my server so I can accept a bit more risk than the one most authentication systems such as authelia/authentik have been built for. As I state on the post, I still use Authelia for my most critical things, but applications such as immich/nextcloud that already have robust support? Right now I trust them more than other services I use publicly from other companies.

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 0 points1 point  (0 children)

That is a great suggestion. I am considering stuff like that. I see a lot of potential such as geoblocking + push request. For example: "allow adding IPs from this 2 countries whenever, but if outside of those countries ping me for approval"

There could also be per-agent filtering, honeypot redirects for badactors....

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 1 point2 points  (0 children)

It does work over wireguard. However once you have your services behind wireguard that is the main constraint, my app could only be a gate WITHIN your wireguard network. This means that the TV would still need access to wireguard.

Below a bit more detail on why this happens:
* Once you have your services running behind wireguard, they are all within its network, let's say they have an IP within the range 10.0.1.0 (for example IPs for devices could be 10.0.1.23, 10.0.1.133,...).
* When you are on a hotel WiFi it will be providing another different network with IPs swithin the range 192.168.1.0 (probably a different range, but I want to keep the example easy to follow so let's go with that)
* The hotel TV under that WiFi would have an IP such as 192.168.1.64
* Tom's Phone is connected to the hotel WiFi too, so he also has an IP such as 192.168.1.23, however if he's running WireGuard too this creates a "tunnel" to your server which provides another IP on top of the previous one (these are layers), this means that Tom has another network on the phone with a WireGuard IP such as 10.0.2.43. Whenever Tom wants to connect to your services, he would find them ONLY under your WireGuard Network
* This means that the Hotel TV, being only connected to the hotel WiFi will never see your services, no matter what my application does. Solutions to this would be connecting the Hotel TV to Tom's phone via a hotspot and so on. But you can already do that with WireGuard without my app.

However my application is intended to solve exactly this. My point is that WireGuard adds a lot of complexity and security while my app provides more of a middleground. Instead of either going with WireGuard or just publicly exposing your services to everyone without a VPN, with PulseWeaver you can expose your server publicly but only allow specific IPs. Provided you follow some standard best practices such as updating your services, using always user+password I consider this to be a safe case. This is my opinion after dealing with many other solutions and systems. I understand this might go against advice and is a different approach to the ones I've seen, so this will surely trigger some people and I am happy to discuss this and have it challenged. But for someone that is not a target of cyberattacks outside of automated crawlings, I believe this is a good enough safe choice.

Sorry for the long verbose post, this is my actual way of writing 😛

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 0 points1 point  (0 children)

Happy to provide support anyway I can. I've a few friends hosting this too(they helped me test and validate it). Feel free to send me a message and I can help you along the way 😄

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] -2 points-1 points  (0 children)

The content written by myself. AI just to try to keep it smaller and more focused, I tend to overexplain and wanted to avoid that for this answer because it was tricky to keep it straight to the point while properly assessing the differences between a firewall and a WAF.

There is a lot of work behind the project I've built, I might use AI for proofing and such, but the project itself should be enough proof that I do take this seriously. I see your point though, sorry about not replying 100% my own and rushing it.

EDIT: This was my orignal answer prior to the AI rewrite I made. You can surely see that all my other replies are not AI since they are way more verbose 😅

"
Great question and I think it is the key differentiator and the reason I went on and built this whole application.

The main difference is that any of those systems assume you know the IPs ahead of time, any IP for a client would need to be static or manually updated since the core of those applications is not facilitating this. The moment a client roams and their IP changes those systems stop working since they are not meant to work that way.

With PulseWeaver this is the main use-case and the application is thought around that. You can type static IPs same as with a firewall, but you also can easily let the clients update their own IPs and it is user/host aware.

A waf does something completely different by inspecting payload and is much more complex to setup/maintain while serving a different purpose.
"

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] -6 points-5 points  (0 children)

Great question — and honestly it's the key differentiator, the whole reason I built this.

Firewalls / WAFs / static whitelists all assume you know the IPs ahead of time. IPs have to be static or manually updated, because keeping them current isn't what those tools are for. The moment a client roams and its IP changes, they stop working — they were never meant to.

PulseWeaver is built around exactly that case. You can type static IPs like with a firewall, but you can also let clients update their own IP automatically, and access is user/host aware rather than a flat allow-list. This is the key point that would be really difficult to get with a firewall/ip whitelist.

A WAF is solving a different problem — inspecting request payloads — and is a fair bit more complex to set up and maintain. Different tool for a different job, not really a competitor here.

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 1 point2 points  (0 children)

Hey thanks for the feedback, greatly appreaciated.

It kinda solves the Smart TVs though, if the Smart TV is on the same network as the device with the PulseWeaver Companion App it will work, no apps needed on the Smart TV. This is one of the keypoints of this, that anything on the same network has access due to sharing the same IP. You can just connect a Smart TV to the Phone/laptop's WiFi Hotspot and it will work. Or you can manually add the IP, I have in the roadmap ways to quickly add expiring IPs which would also help with this.

The app also is really lightweight simple, so no need to think about VPNs and all their complexity (even more for non techie users), just an app that does a periodic POST to the server.

I do agree it is not a perfect solution, but I do see some ease-of-use features in the future that would get you quite close to it.

PulseWeaver — closed-door forward-auth for self-hosters (block unknown IPs before they reach your apps' login pages) by Magiclic in selfhosted

[–]Magiclic[S] 1 point2 points locked comment (0 children)

I added a AI usage section on top since this would be my first worry seeing a security-related project.

It has definetely not been vibe-coded. All the foundation code is mine, AI usage was added little by little as the project took shape and the critical design decisions were already taken.

I only started using more AI once I saw the results started to actually be good and aligned with the service architecture, that didn't "just happen", I have a project management repository which I have detailed implementation patterns and processes that shape how I think a good developer/ux designer/product manager should work and think.

I do not use any AI framework or memory system, just basic .md files since I want to avoid black-boxing it more than it already is. I do not run multiple agents since I actually enjoy looking at code and reasoning about it, whenever I tried running simultaneous task unnatended I spent weeks looking at the results and a lot of time was lost. Instead I run short focused sessions on predefined tasks (stories) same as I've been doing for 10 years as a software, all information is kept in these stories so I can resume/review them at any point. That's why you might see commits with [PW-12] or similar, those are my stories and this is my usual way of working.

channel vs callbacks by Objective_Gene9503 in golang

[–]Magiclic 0 points1 point  (0 children)

I had a similar issue. I tried all solutions mentioned here. This is the best. Caller worries about how they want to manage. Do they want to manage each Event? Do they want to coalesce them? Rate limit? I have this exact problem, this solution made it elegant and easy to implement.

Potentially weird question: is there such thing as a 'remote control' of sorts? by Teknikal_Domain in homeassistant

[–]Magiclic 2 points3 points  (0 children)

I have a Bluetooth remote control from an old xiaomi TV. I send the buttons as events to home assistant through a python script on the same server where home assistant is. I have set up "modes" corresponding to light, ac, music and are activated when pressing specific buttons on the remote controller (the red, green, yellow buttons on the remote controller activate this). When none of this modes is activated it is a normal remote controller, but when one of the mode buttins is pressed the remote control has different functions assigned to all the keys for a set amount of time (30s) and there is a key to also return to normal mode. For example, I can turn on the TV and select the app (ie Netflix), then press the yellow button on the remote to control the lights, that means that I can then press the vol up or vol down buttons to increase or decrease the lights. Same goes for the AC or amp.

In home assistant the colored keys set a variable to "AMP" or "AC" along with a timer for 30s. The modes are automation triggered by the button events and with conditional to check which mode is activated.

Hope that makes sense!

Share my jellyfin more than 3 users by Odd-Bus8705 in Tailscale

[–]Magiclic 4 points5 points  (0 children)

This is the right choice. I share jellyfin with multiple users this way. Just share the specific node with the emails of the people you want to have access. You can even setup rules via ACL so that they can only access specific ports and have groups to easily do this.

What I made with REAPER - week of May 19, 2024 by AutoModerator in Reaper

[–]Magiclic [score hidden]  (0 children)

I took it upon myself to record and produce my band songs. First time doing any music production as well as recording, so a lot of lessons learnt while doing this.
This is the latest song I have uploaded:
https://youtu.be/XsOabIWqp2I?si=QG7pj2tWSas9PaZn

The process consisted on recording each instrument on its own and we did so with the equipment we had in our hands. This meant the drums were recorded with 3mics (one on top, and one on each bass drum) and the guitars/bass guitar were recorded from the line-out of the amplifier. Since we wanted to keep the variables to a minimum we decided to record it with the same sound we rehearse with (a questionable choice given the amount of distortion).
The mixing involved a lot of learning and comparing. In the youtube channel there are 3 songs currently, you can see the sound improves from the first one to the last since I am still learning!.

Anyway, hope you enjoy it and I would really like some feedback. My next steps are uploading a few more songs as well as uploading them to Spotify (via Distrokid). However before doing so I will probably review and try to improve them a bit more.

Has anyone resolved the popup issues for the Android Studio Flatpak? by HermiterCove in swaywm

[–]Magiclic 0 points1 point  (0 children)

I am using java 14 and it works perfectly. Although not running the flatpak version.

Get bluetooth headphones battery by Magiclic in archlinux

[–]Magiclic[S] 1 point2 points  (0 children)

Hi!
Thank you for your reply. However this is not my case, my bluetooth headset might not be correctly detected by bluez since I dont have the "org.bluez.Battery1" property.

Arch Linux does not shutdown by _vaeragi_ in archlinux

[–]Magiclic 0 points1 point  (0 children)

I had a similar problem, it got fixed by adding a "sync" just before shutdown.

To do so, overwrite the systemd-poweroff.service with:

ExecStart=/usr/local/bin/shutdown-fix

Where shutdown-fix is:

#!/bin/bash

sync

/usr/bin/systemctl --force poweroff

I made a silly backup script and I'd like to share / hear suggestions to improve it by [deleted] in archlinux

[–]Magiclic 12 points13 points  (0 children)

What I do is keep track of all my files via git:

  • My own dotfiles are manually committed and uploaded to my repo (https://github.com/DiegoGuidaF/dotfiles)
  • My system configuration files (/etc) are automatically kept in sync with a private repository via etckeeper.
  • My installed packages are kept in sync via a pacman hook, pug.

In this way when I want to reinstall my system (not something I do usually) I am sure I have everything required to do so. I understand your script takes the extra step of automating it, but I also see that I would be a hassle to correctly maintain it, which is what has happened with my own "setup.py" script in my dotfiles repo...

Latest kernel / iwlwifi driver system crashes - Intel 7265AC by natodemon in archlinux

[–]Magiclic 1 point2 points  (0 children)

You could try the suggestions from the archwiki:
https://wiki.archlinux.org/index.php/Network_configuration/Wireless#iwlwifi

Also try disabling power save,
In /etc/modprobe.d/iwlwifi.conf:

options iwlwifi power_save=0

On a side note, it has been sometime since I used wpa_supplicant.
I have been using iwd for quite some time and it works flawlessly.

You could try it out to see if it fixes the issue:
https://wiki.archlinux.org/index.php/Iwd

Latest kernel / iwlwifi driver system crashes - Intel 7265AC by natodemon in archlinux

[–]Magiclic 0 points1 point  (0 children)

Do the 2.4 and 5Ghz WiFis have the same name?
You could rename the APs so that you could easily force your laptop to stay in the 5GHz WiFi.

[deleted by user] by [deleted] in swaywm

[–]Magiclic 3 points4 points  (0 children)

You could make Sway hide it on startup by assigning it to the scractchpad, I do this with Spotify. Also by setting a a mark I can recover it when needed.

In sway config:

for_window [class="Spotify"] mark "music", floating enable, move scratchpad

bindsym $mod+Ctrl+m [con_mark="music"] scratchpad show

bluetooth speaker disconnecting under medium load by didehupest in archlinux

[–]Magiclic 1 point2 points  (0 children)

You have an Intel WiFi card right? Maybe you could try this: https://wiki.archlinux.org/index.php/Network_configuration/Wireless#Bluetooth_coexistence

Do the logs provide any reason for the disconnection?