Removing X-Frame-Options in ASP.NET MVC Core 7

I had an ASP.NET Core 7 App that used forms.

And I actually WANTED it to be used within an iFrame.

As soon as you add a form to a Web App, the server immediately starts returning X-Frame-Options: SameOrigin in all requests.

I tried a variety of means to remove this, including:

app.UseStaticFiles();

            app.Use(async (context, next) =>

            {

                context.Response.Headers.Remove("X-Frame-Options");

                context.Response.Headers.Add("Bob", "Hello");

                await next.Invoke();

            });

            app.UseRouting();

The Bob header was being added, but X-Frame-Options stubbonly remained.

In the end I found the solution was to use:

// Remove X-Frame-Options, allowing Framing

            builder.Services.AddAntiforgery(options =>

            {

                options.SuppressXFrameOptionsHeader = true;

            });

The ASP.NET Core security headers guide (elmah.io)

Enable Cross-Origin Requests (CORS) in ASP.NET Core | Microsoft Learn

ASP.NET Core Middleware | Microsoft Learn

Transferring domains to Google

I decided to leave 123-reg after they chose to upgrade their email services and removed catch-all email forwarding. I found a slight issue when transferring Nominet (.uk) domains to Google. The transfer process requires Google to send a handshake email to the registrant's email address, requesting them to approve the transfer. However, if you don't have a gmail address registered, you don't seem to get an email. So it is important to set the registrant's contact email to a Gmail address first, before setting the IPS tag.

FreeBSD discretionary ACLs

 As well as the normal user,group,all file permissions, my FreeBSD server had additional ACLs that were preventing the NFS client from accessing files.

To solve this, use setfacl:

setfacl -bn *

Docker bind mount assumes ownership of container user

I had a mosquitto image running in Docker, with a bind mount:

docker run -it --name mosquitto -p 1883:1883  -v /home/pi/mosquitto/mosquitto:/mosquitto/ -v ~/mosquitto/mosquitto/log:/mosquitto/log -v ~/mosquitto/mosquitto/data:/mosquitto/data  eclipse-mosquitto

Before I ran the container: I created the source folder and set the owner to pi:

sudo chown -R pi /home/pi/mosquitto/

Yielding the following permissions

drwxr-xr-x  5 pi 1883 4096 Feb 19 20:14 mosquitto

On running the container the folder changes permissions:

drwxr-xr-x  5 1883 1883 4096 Feb 19 20:14 mosquitto

Debugging the container:

docker exec -it mosquitto /bin/sh

and checking the users:

sudo nano /etc/passwd

It can be seen that UID 1883 is the mosquitto user:

mosquitto:x:1883:1883:mosquitto:/var/empty:/sbin/nologin

Linux utilities

The strace program prints all the system calls made by a program.

strace ls -lhn $(which sleep) 2>&1 | grep passwd
What you are trying to see is whether ls command is trying to read the /etc/passwd file or not.
Networking tools:
Performance tools:

Pe

Setting a password remotely when you can't login to RDP

 How to change your own expired password when you can't login to RDP - Evotec

Fine Offset WH1080 Weather Station and a Raspberry Pi

To receive the weather readings from a WH1080 by radio, you can use a SDR USB with a Raspberry Pi 3/4, however it will not work with a Raspberry Pi as it is's power requirements are too high. The SDR USBs draw considerable current from the USB port as they are powering the amplifier.

The appeal of using a Pi Zero is it's low power usage - it is approximately 0.7W (120mA) compare to a Pi 4's 5.1W (1010mA).

So we need another radio receiver. The RFM01 and RFM12b are candidates, and this article describes using them with a Raspberry Pi.

My weather station transmits data on 868Mhz, using Frequency Shift Keying (FSK). This is where a digital '1' is transmitted at one frequency and the '0' at another.

Video: 433Mhz with the Pi

Code for controlling the RFM01 with SPI on the Pi.