Look, if it was a random kid on tiktok that's one thing, but slinging (potentially) slanderous information around (and publishing it, technically) is a serious matter with real-world consequences. If someone made a blog post about how you torture animals and have a horrible taste in music, you'd probably want to do something about it.
Well, the CORS thing is just your browser protecting you from an XSS attack. So the API just needs to advertise the origins that are permitted. Like writing "stolen from xyz" on your tools.
The tricky part with electrical will be which things get missed. Like finding out the microwave has its own circuit that's shared with the bathroom fan or something. What you could do is buy 50 IoT devices and record which ones connect to your wifi after you start flipping breakers. You might be able to do some clever bracket to determine which outlets are on which circuit, but hardwired appliances will be more manual.
I like the approach Jetbrains has taken with extension libs to add functionality that could've been in a bloated standard library.
No, i just don't want to see misinformation period. The reason the printer wasn't working is because they were on a managed printing plan, not because HP was trying to pull one over on them.
I just don't see the point in spreading misinformation. I have had almost entirely bad experiences with HP, but that doesn't mean I go around spreading lies.
Microsoft Word for my resume. I'm not sure what I can do to change that, I don't want to risk a(n accidentally) badly formatted resume losing me an opportunity...
Here's a simple approach:
- Basic auth via a custom header, like X-Auth
- JWT auth on Authorization header
- uuid on the JWT (as a claim) that gets stored temporarily (until it expires) to allow the server to revoke the token
Initial request -> server looks for Authorization header, falls back to X-Auth header -> generates JWT and sends back to client in Authorization header (or whatever makes sense)
Subsequent request -> server looks for Authorization header -> checks JWT against revocation database/table and that it isn't expired
Subsequent request with expired token -> server returns 401, client retries using X-Auth header -> server sends back JWT on Authorization header -> client updates locally-stored JWT for future requests
There are probably ways to make this more standard or optimal, but this is a simple approach.
It can depend. Sometimes sprawl is car-centric because it's heavily developed with no alternative, but sometimes there'a a lot of undeveloped land in between things.
I live somewhere that never had anything but car infrastructure. Should I ride my bike across a 5 line intersection to go to the mall? And before you suggest my local government install a light rail from my house to the mall, I'm surrounded by farmland.
Not all the dependencies are supported on aarch64 unfortunately.
Unfortunately I was trying to build WebRTC, which is supported on Linux only.
I'd still prefer code over a DSL. In fact, I just like Flutter. Hot reload and no fighting XML-as-a-DSL.