I knew it was possible to generate QR codes to access quest networks (as the QR code has credentials) for WiFi networks having a fixed SSID.
I just never bothered, but did when needed home care with quite a few different people providing the care.
Generating was easier than I anticipated, though I hoped I just could put the parameters in a URL and fire off to get a page including the QR code.
Alas, the pages I found require you to enter the SSID name and key/password phrase.
That’s OK: I have saved the PNG files for our network and my brother’s as images so I can put them on-line, and printed them out so guests can scan and use the network at once.
The IP you are accessing the site with (037.153.243.242) has been blocked because it has triggered one of our security measures. Please see the reason below:
Block reason: This IP was identified as infiltrated and is being used by sci-hub as a proxy.
To restore access, please contact onlinesupport@sagepub.com citing this message in full.
I checked the router and web-proxy for any suspicious activity. There is none.
I do run the ArchiveBot by the ArchiveTeam to support the WayBackMachine of the InternetArchive and the great team Mark Graham has there providing some bandwidth and CPU/memory resources helping them archive public internet content for posterity.
iOS has forced Safari to be the only web browser since forever, so Google started to use the googlechrome:scheme to force Chrome as browser on it a while ago
Yesterday and today, he is maintaining a Twitter thread on things that have broken.
Quite a few things have, including some versions of curl, on which a lot of infrastructure relies (the certificate for it got fixed later on 20120930), see:
Yes, I know the pluimers.com web server is rated B from a TLS perspective. Will be working on it, but I’m still recovering from rectum cancer treatments, and have an almost 1.5 year backlog to get through.
Let’s Encrypt has done loads of work over the past lustrum to prevent trouble like cross-signing, issuing the successor certificates, and more.
The problem is that people like you and me have refrained from keeping their clients and servers up-to-date, so some security issues will occur. Hopefully they are limited to non-functioning communication and not leaking of data.
In my case, I had to scale up (by a 25% so a factor 1.25) instead of scale down.
What I observed so far in recent Chrome versions is:
The wrapping div is still needed, otherwise the outer size and inner size of the frame mismatches
The wrapping div and the wrapped iframe need to have the same dimensions (so unlike the Stack Overflow answers, no need to scale the width/height of the div; keep the same values as the iframe)
The div uses class calendar_wrap.
The iframe uses class calendar_iframe.
This is part of my CSS:
body {
margin: 0; /* override browser setting for body `margin: 8px;` */
overflow: hidden; /* remove scroll bars; does not work for iframes */
}
/* ... */
iframe {
border-width: 0; /* override browser setting for iframe `border-width: 2px; */
height: 100vh;
width: 50vw;
overflow: hidden; /* remove scroll bars; does not work for iframes */
}
/* wrap and iframe zoom as per https://stackoverflow.com/questions/166160/how-can-i-scale-the-content-of-an-iframe */
.calendar_wrap {
float: left;
height: 70vh;
width: 35vw; /* calc(35vw / 1.25); */
padding: 0;
background-color: blue;
}
.calendar_iframe {
float: left;
width: 35vw;
-ms-transform: scale(1.25);
-moz-transform: scale(1.25);
-o-transform: scale(1.25);
-webkit-transform: scale(1.25);
transform: scale(1.25);
-ms-transform-origin: 0 0;
-moz-transform-origin: 0 0;
-o-transform-origin: 0 0;
-webkit-transform-origin: 0 0;
transform-origin: 0 0;
}
/* ... */
The Wiert Corner - irregular stream of stuff 