Connect on your phone or other device. Connect to travel router. Clone the mac address of your device. Connect router to wifi. Adjust device to not auto login. Good to go.
GL.iNet routers don't even need this. It has an option to pass through captive portals. So you connect to your GL.iNet AP, then you set it up for the hotel WiFi, tick the option for passing through (it essentially disables VPN, AdGuard Home and other things if enabled), it will then link you to the captive portal where you can log in as you would otherwise.
Once the internet is active, the GL.iNet router will then re-enable things like VPN and AdGuard Home.
Since these devices are OpenWrt underneath with a pretier ui, I presume this is all possible on any OpenWrt device.
This is just flat-out untrue, OIDC or SAML plus SCIM should be the default for any enterprise-focused service provider or "you're doing it wrong". You can offer your own IDP as the default, but all of the problems that need to be solved to allow your customers to configure their own IDP are important to the design/architecture of your service and the only reason these providers are treating it as special is because they didn't build the integration between their service and their IDP correctly the first time. Provisioning and authentication are critical to security and you're actively harming your customers if you require them to use your own IDP solution in order to use your service.
As a volunteer at a volunteer run non-profit, I agree! Nobody makes any more at the org, and it would be great to have SSO for things without having to pay more 150% of our total annual budget to get it...
It's really fun when your ISP starts using CG-NAT as a security feature in marketing. You ask them for a static IP and they have you sign an agreement that you won't be getting the BENEFITS of their CUSTOMER FIREWALL. Yeah ok, so if that's the language around this then we're just screwed aren't we? And you also can't tell me when you're planning to support IPv6 of course.
>they have you sign an agreement that you won't be getting the BENEFITS of their CUSTOMER FIREWALL
Sounds like the legal department didn't want them to get sued for "negligence" or whatever when some customer exposes their windows server 2008 installation to the internet and promptly gets hacked.
Remember even if timestamps may be generated using a monotonically increasing value that does not mean they were committed in the same order to the database. It is an entirely separate problem if you are trying to actually determine what rows are "new" versus "previously seen" for things like cursor-based APIs and background job processing. This problem exists even with things like a serial/autoincrement primary key.
What could be useful here is if postgres provided a way to determine the latest frozen uuid. This could be a few ms behind the last committed uuid but should guarantee that no new rows will land before the frozen uuid. Then we can use a single cursor track previously seen.
I'm a huge proponent of using SQLite as an abstraction over a filesystem. One warning I will note though, is be aware that a SQLite database does not shrink unless you vacuum it (basically copies the data into a separate file and deletes the original). This is a manual operation you have to do at points where it makes sense within your application. So be careful with disk usage when just writing binary data and then deleting it.
SQLAlchemy and your efforts are so amazing and appreciated. Thank you and the team for all of your hard work on 2.0 as well as the heroic effort that was put into 1.4 as a stepping stone for existing codebases!
To be fair they are quite up front when you stake Ethereum that you cannot withdraw it before the network itself supports it... Hope they re-activate your account though!
That's for using macOS input devices to control iPadOS. I was interested in using something on my phone to control my mac. From what I can tell "Switch Control" is probably it, but it looks pretty tricky to setup so far!
I have plenty of shortcuts that work on iOS but don't work on macOS. It's fun when you use siri on the mac and it tells you it can't do something halfway through.
The promise of thread versus reality I feel will be a big problem - I'd love to be wrong though. I'm on the outside of things (haven't used thread, only read about it... use zigbee a lot though). But the way I understand it is that once you join a device to a particular bridge you will still need to use that bridge's ecosystem to communicate - even though the device has its own IP address. For example, when a thread device joins to homekit and establishes an encrypted handshake, it's not like I'll be able to use that device's IP address to talk to it. It's not going to trust me - only homekit. But at least it'll be able to talk to any homekit bridge on the network and avoid a SPOF if I unplug one of my homepod minis.
