toad.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server operated by David Troy, a tech pioneer and investigative journalist addressing threats to democracy. Thoughtful participation and discussion welcome.

Administered by:

Server stats:

258
active users

#localhost

0 posts0 participants0 posts today

A #browser on an #android #android15 device, connected to a #wifi #hotspot network cannot access a GUI in a browser at
<ip address>:8000
served by a #localhost computer with <ipaddress> in the hotspot network.
In my case a #raspberrypi is the local host, & is serving the GUI & also running the wifi hotspot.
On #linux and #apple devices in the hotspot wifi network this works fine, & putting <ip address>:8000 into a browser serves up the GUI from the pi to the browser. Can this work on Android?

Continued thread

@small-tech/https version 5.3.0 released

• Uses Auto Encrypt 4.1.1 (removes OCSP stapling support because Let]s Encrypt has removed OCSP support).

npmjs.com/package/@small-tech/

This module is a drop in replacement for Node HTTPS module that automatically handles TLS certificate provisioning and renewal both at localhost (via Auto Encrypt Localhost¹) and at hostname (via Auto Encrypt with Let’s Encrypt certificates²).

So, this is how you create a HTTPS server in Node.js that uses this module and automatically handles TLS certificate provisioning and renewal for you both at localhost (during development) and at hostname (during production):

```js
import https from '@small-tech/https'

const server = https.createServer((request, response) => {
response.end('Hello, world!')
})

server.listen(443, () => {
console.log(' 🎉 Server running at https://localhost.')
})
```

(Yes, that’s it! I wrote a metric shit-tonne of meticulously-tested code so you don’t have to.) :)

💡 Note that the localhost certificate support via Auto Encrypt Localhost is 100% JavaScript and does NOT rely on an external binary like mkcert or certutil.

Needless to say, Kitten³ uses this module under the hood and it’s a big part of why Domain⁴ can deploy servers so easily that don’t require any day-to-day maintenance.

In case you’re wondering why I’m spending so much time releasing all these modules, it’s because I believe in sharing every brick of the house I’m building so others can easily build different houses if they want to. I’m not saying that what I’m building with Kitten, Domain, and Place⁵ will be the end all be all of the Small Web⁶ (the peer-to-peer web). And I want others to be able to experiment by building their own tools without having to go through the grueling development process I’ve had to in the past six years to build basic infrastructure.

Enjoy!

💕

¹ codeberg.org/small-tech/auto-e
² codeberg.org/small-tech/auto-e
³ kitten.small-web.org
codeberg.org/domain/app
codeberg.org/place/app
ar.al/2024/06/24/small-web-com

npm@small-tech/httpsA drop-in standard Node.js HTTPS module replacement with both automatic development-time (localhost) certificates via Auto Encrypt Localhost and automatic production certificates via Auto Encrypt.. Latest version: 5.3.0, last published: 12 minutes ago. Start using @small-tech/https in your project by running `npm i @small-tech/https`. There are 2 other projects in the npm registry using @small-tech/https.

What's the easiest way to set up (e.g. using a nice script or other program) a local #DNS on a range of platforms, and configure it to handle wildcard subdomains on #localhost?

😆

A quick search shows #dnsmasq can be used on Linux and Windows at least, but I wonder if anyone has faced this problem before and made a neat cross-platform solution?

I want <anything>.localhost to resolve to localhost and be handled by a server which runs on the local device (ideally Win, Mac, Linux and Android).

0.0.0.0 Day: Exploiting #Localhost APIs From the Browser

Websites can can communicate with services running on the local network by using 0.0.0.0. This could lead to arbitrary code execution on the site visitor's device.

Fixes by different #browsers are on the way and in different stages:

WebKit (#Apple) blocks access to 0.0.0.0 for Private Network Access.

#Firefox now blocks 0.0.0.0 but has not implemented Private Network Access.

Chromium browsers strting with 128 will be updated to block access to 0.0.0.0

#privacy #security

oligo.security/blog/0-0-0-0-da

www.oligo.security0.0.0.0 Day: Exploiting Localhost APIs From the Browser | Oligo SecurityOligo Security's research team recently disclosed the “0.0.0.0 Day” vulnerability. This vulnerability allows malicious websites to bypass browser security and interact with services running on an organization’s local network

and.... we're up and running.

My blog has moved to a server at home and appears to be running OK.

What did I do differently from yesterday? Glad you asked. I took it very slowly..

I started by enabling connectivity over http and waited patiently for DNS to propagate and test OK before proceeding. I think I broke DNS yesterday (didn't use the FQDN in the CNAME even though that's not how it's displayed once saved) which didn't help.

Once it was OK serving http pages, I checked all the settings for acme-client and I was missing a couple of directories which I created. The first acme-client test worked and we had a cert. I removed the comments from the TLS config in httpd.conf and restarted and things are happy again.

If anyone's interested in my random life notes and occasional home automation and solar posts, you can find me at martin.hatstand.org.uk

(/braces for the server onslaught as both of my followers click the link....)