neocities blogs made easier

[april]

Bloggable
Ever since the restrictive content security policies were implemented on neocities it became increasingly difficult to implement dynamic features into the static sites. As the policy allows same site requests through iframe trickery i have put together a blogging (but can be used for arbitrary data) platform for free neocities accounts. It reduces the need to redo html and css by providing a simpler WYSIWYG editor to post messages. It is entierly up to the user to change the css and the js and templates are provided for some starting off points.

Here are some screenshots

[Dan Q]

Wow! I had no idea that Neocities had added connect-src 'self' data: blob:; form-action 'self'; to their CSP. What a nightmare!

I'm pretty sure an enterprising individual could work-around such things in anything they really wanted to implement a server-side-thing that Neocities users could embed using JS...

For example:

There's no fetch and no form submissions, but data can still be sent to a remote server in a media URL, right? So if you had a guestbook component or similar, the JS could take the submitted comment, put it into a URL as a GET request, then use that as the source of an image, remote JavaScript, iframe, or similar.

Similarly, data can be remotely-fetched via images, but it's a lot more-complicated! First, the dynamic server would need to encode the data in a way that allows it to be represented as an image. This could be pretty simple: just binary-encode the whole thing (possibly after compression) and treat each 8-bit block as a "pixel" of an 8-bit PNG image. Pad the end so you get a round number of 8-bit blocks. Render that as a PNG. The restricted site can use JS to render the PNG into a <canvas> element, extract the colors, convert it back to a binary string, and decode it. Tada: data!

Perhaps the best way to remotely-fetch data would be through self-evaluating JSON. This trick was quite popular when Ajax was just starting to use JSON but not all browsers supported it. A great thing about it is that it's really easy to bolt "on top" of an existing JSON endpoint! So if normally you'd request //example.com/api/something.json using fetch, now you'd request //example.com/api/something.json?call=functionName, using a <script> tag. The server generates the same JSON, but instead of sending it raw it puts it into a JavaScript that passed it to the specified function (functionName, in this case) to its value. With this, the restricted Neocities site can just say "run the script over there, which will execute my functionName with the response". It's old-school, but it should work.

I might put together a proof-of-concept to show it can be done.

[Dan Q]

JSONP! That's what we used to call the technique!

I completely forgot the name for a while there.

[april]

I think the pass through iframe method is relativey decent for get requests on data as it just puts all the posts in a posts array which the user can edit freely/do whatever they want with.

Code

window.parent.postMessage(
    { type: "POSTS_DATA", posts },
    "*"
);

this is the important part of the code which sends the message from the iframe to the parent website. Im not sure if posts requests through iframe would work... idk im not smart enough lol! If you do make a proof on concept please share i would love to see it!

https://content-security-policy.neocities.org/

btw if you havent seen heres a good website detailing the content security policy

[Dan Q]

https://content-security-policy.neocities.org/

btw if you havent seen heres a good website detailing the content security policy

I found that first, but I wasn't happy with it so I just looked at the actual headers Neocities was sending. Thanks though, moderately good resource and well-researched!

this is the important part of the code which sends the message from the iframe to the parent website. Im not sure if posts requests through iframe would work... idk im not smart enough lol! If you do make a proof on concept please share i would love to see it!

Just threw one together! Take a look at https://embed-html.neocities.org/poc!

It's a chat room! If you look at the source for that page you'll see that the JS comes from a remote server... and (obviously) the chat room itself comes from a remote server. But it's not an iframe... and yet it still works on Neocities! Amazing!

It's using the JSONP architecture. Here's how it works:

1. The Neocities page includes some JS from the remote server. This bit's easy.
2. To fetch data (recent chat messages) from the remote server, the JS creates a new script tag that looks like this (tidying up any previous script tags it made along the way):

Code

<script src="https://danq.me/_q23u/neocities-fetch-workaround-poc/poll.php?callback=miniChat_callback_4b292b357e1d422bb7b586d643473a9c"></script>

Because it's a <script>, not a fetch, it doesn't get blocked by Neocities' CSP. The "callback=" at the end specifies the name of a function on the Neocities page to "give" the resulting JSON to: it's randomly-generated when the main JS runs.

The endpoint (e.g. poll.php) returns JSON, but wrapped in miniChat_callback_4b292b357e1d422bb7b586d643473a9c( ... ). This way, the JSON is the input to the function defined by the JS, and the data comes through.

3. To send data (new messages!) back to the server, I use the same technique: a <script> tag. These ones look a bit like this:

Code

<script src="https://danq.me/_q23u/neocities-fetch-workaround-poc/send.php?callback=miniChat_callback_4b292b357e1d422bb7b586d643473a9c&name=Your+Name&message=What+did+you+say"></script>

Same deal. It's done over a <script>'s GET request, which are not blocked by Neocities. It could equally work with an image or iframe src, of course: I'm using a script because I want to handle the response in the same way as I do when polling for new messages.

This approach isn't so suitable for very large payloads: they have to fit into a URL! For maximum compatibility, that means you're capping out at sending 2Kb of data at a time (you can receive as much as you want, of course). But for something larger, it'd be absolutely possible to break it up and send it in several chunks, I suppose! And you could add compression, too: JS implementations of deflate etc. are perfectly solid these days.

So yeah: it's 100% work-aroundable, I think!

[Dan Q]

Oh, and here's all the source code.

[april]

This is very cool and def works well! I would implement something like it but i think there are better options for whatever people like to post data with blogs (e.g like guestbook or comment boxes as they have special allowances by neocities) also i think my firebase free plan would not enjoy even more reads/writes lol! Idk if you can do uhh continuous listeners... snapshot listeners i think thats the term for it like where the page doesnt need to refresh each time to load the data back but thats not really too big of an issue for like comment boxes and the like. The reason i actually made it an iframe is that i was talking to the guy who made https://iframe.chat/ chattable at the time and that was the way he did his chat box (also the reason i used firebase which was kinda a mistake cause i hate firebase). Anyway he seemed way more experience with webdev than me so i followed in his footsteps. I will def be putting this technique in my back pocket tho as it is a really nice workaround!

 

oh yeah all my code is on github uhhhh here https://github.com/apriltilde/bloggable yes!

[Dan Q]

Nice. Thanks for dropping by.

Yeah: I remember I first started using Firebase shortly after it came out, long before it was acquired by Google. Initially what it did seemed like black magic. But now that websockets and data binding have become easier, it just feels cumbersome to use Firebase!

Yeah, a big weakness of my approach is it requires polling, so it's not great for realtime stuff (maybe a chat room wasn't the right example project!); it can't do a websocket like you can in an iframe. But for lightweight stuff and where you want it to be able to be styled by the end-user, I like my approach. E.g. a hit counter/like counter or even a guestbook would work wonderfully this way.