Prefacing by saying I’m a total noob to webdev.
I’m trying to move my personal portfolio site off of Squarespace and onto some sort of static hosting. Since I know nothing, I’m cobbling together hugo templates and using LightBox2 to show image galleries. The blog I’m referencing includes LightBox2 using this:
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/lightbox2/2.11.1/js/lightbox.min.js" integrity="sha256-CtKylYan+AJuoH8jrMht1+1PMhMqrKnB8K5g012WN5I=" crossorigin="anonymous"></script>
I would prefer to not subject people viewing my page to any external tracking if I can avoid it. My page has zero tracking/analytics for this reason. I briefly tried downloading LightBox2 and directly including it instead, and was able to get it working mostly, but some things were broken that I would need to debug. Before I do that I was wondering, is this even a problem? Is including stuff from cloudflare cdn like this sketchy? It’s possible I’m being overly paranoid but I have no idea.
You must log in or register to comment.
I don’t trust cloudflare. That is just a JS CDN that pulls a file, but is still gathered from an external server. In my case, when I have to use CDNs to use a JS library, I just download the file and host it locally.
You don’t own the CDN, is controlled by other people, which means that of course is less private to the end user, and more insecure since you rely on the people running the CDN and the author or the library. What would happen if the library author/authors get hacked and they add malicious code to the library? (Asumming it doesn’t contain a
integrityattribute like the one on your example).Is better to trust yourself, it doesn’t cost you anything to download a few kB of a JS file and serve it directly from your server. The page is not going to load 2s faster if you use a JS CDN
And no one wants this to occur to their websites: https://fossa.com/blog/polyfill-supply-chain-attack-details-fixes/
Might I recommend github pages? Should be able to host all needed dependencies there too.
PS - jerboa android client didn’t show your markup, may I also suggest using 3x backticks to make it formatted as you expected? Like so:
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/lightbox2/2.11.1/css/lightbox.min.css" integrity="sha256-tBxlolRHP9uMsEFKVk+hk//ekOlXOixLKvye5W2WR5c=" crossorigin="anonymous" /> <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/lightbox2/2.11.1/js/lightbox.min.js" integrity="sha256-CtKylYan+AJuoH8jrMht1+1PMhMqrKnB8K5g012WN5I=" crossorigin="anonymous"></script>I would recommend gitlab pages over github pages. Github is owned by Microsoft so who knows how private it is anymore.
Yea, that’s smarter. I didn’t know they had that as well, but in hindsight it makes sense
Thanks fixed. Interesting jerboa and the web version of lemmy are developed by the same person but using the “code” button in the web frontend only uses one backtick. That might be worth a bug report.
I’m actually trying to get away from github also, so maybe codeberg pages instead? This is a part of the process I haven’t done enough research into, I wanted to get the static site working locally first then “shop around” for hosts.
There’s a few issues with jerboa that I’d like addressed, maybe I’ll look into building it and issuing some PRs for it when I have more time. Can’t imagine it’s easy to maintain such a code base alone.
Few things off the top of my head are keyboard hides text with long comments, and sharing links for federated communities gives a link to the instance it was posted on and not the instance I’m on.
Also not being able to make communities in jerboa is a bit of a bummer, should also be easier to subscribe to communities on other instances too (web client).
One way or another, the server that hosts a resource can track who is requesting what. You as the server owner can just as easily track who is accessing what, but if you avoid using a CDN, then it limits the tracker to just yourself. The cost is that you’ll have increased traffic, and there is always the suspicion that you may have tampered with the
lightbox.jsfile to do something malicious.On the self include side, the instructions you linked seem pretty straightforward, so it should be possible to use it that way. What is issue your facing?
The issue seems to be with how hugo renders everything down into a /public directory. Somehow this is breaking the static images Lightbox uses to do prev/next/close. It’s a small issue and I’m sure the fix is something dumb, it just wasn’t obvious to me (the images appear to be correct). But sounds like it’s worth just debugging it…
How would things break from including it yourself? Just download the file from the links in your post and include them on your webserver it shouldn’t require any code changes beyond that. You also never know if they would take down an old version or if some outage will occur so I’d personally rather host them instead of relying on additional servers to work.
Something about how hugo is cooking everything down into a /public directory is breaking the overlay images (like the next/prev arrow). I’m sure I can track it down but since I’m pretty inexperienced this will take me some time (at cursory glance all the paths seemed good, so I’m not sure why it’s broken).
I would also prefer to host it myself so maybe I should just do this…
Looks like
../images/loading.gif…/ means previous directory so off CSS is public/css you want public/images.
OK, looks like the image paths are correct. It’s something about the JS that fades them in. If I toggle the opacity property on/off then suddenly it works fine, until I refresh, so something funky is going on there. At least I know the structure is correct hugo-wise so it’s just a matter of tracking down the fade-in issue.
Yeah I see nothing that using a local version that would cause that… Hmm next I would try mixing CDN ref and local ref for js/CSS try to pinpoint what one is making it buggy.
I’m starting to think it’s something super specific to the particular hugo theme I’m using and how it wants users to insert custom js/css to get it all baked down into the right place in the final output. I’ll keep bashing on it, thanks for your help!
Edit: OK this is kind of hilarious considering the community I posted to, but I actually think it works fine but something about my Librewolf setup is breaking it. It works fine in Firefox and Chrome, and since I jump around between them as I work I just happened to test in Librewolf right as I made this change. Not to get too far into the weeds but I think I’m going to just go ahead with not linking cloudflare. Thanks again.
Ah I didn’t think of the image references! Yeah probably better off downloading the whole library when it requires the other assets too. Its likely soft linking at point of the css file and you’d need assets paths stored in reference to the CSS file.
Why are you using some random blog post? The page you linked to shows how to use it without Cloudflare…
