Commit graph

28 commits

Author SHA1 Message Date
58d7c38523 Simplify CSP header for SWF asset embeds, to fix 502 for some assets
Fun little bug: viewing the "Engulfed in Flames Effect" item was
showing our "502 Bad Gateway" custom error page in the embed. This is
because the Rails app was providing a `Content-Security-Policy` header
value that was longer than nginx is configured by default to allow, so
it was refusing the response, and showing the same 502 error as if the
app hadn't responded at all. (We discovered this by opening
`/var/log/nginx/error.log`, which explained this very clearly, ty~!)

In this change, we no longer list every `images.neopets.com` asset,
instead marking the entire domain as a valid image source for the
SWF asset embed iframe. I don't _love_ this solution, I liked the
property of specifying literally exactly the assets we allow! But I
don't think there's any practical danger here, and it helps a *lot* for
making this more reliable.

(If we could have solved this reliably by increasing nginx's allowed
response header size, I probably would've done that? But I researched a
bit, and ultimately concluded that I don't trust other intermediary
software like firewalls not to have the same issue. Let's not be
pushing the limits of HTTP headers of all things!)
2024-09-12 15:59:18 -07:00
7ec900b6b6 Use {script,style}_src instead of _elem, for better compatibility
Oh, I didn't realize the `_elem` variant of these parts of the
`Content-Security-Policy` is newer, and so doesn't even work on my
current version of Safari on my Mac.

My rationale at the time was: `script_src_elem` is stricter against
things like imports, and I figured, ok let's do the strictest policy
that works. But since it's not fully compatible with browsers even
*I'm* using right now, and I'm not aware of an actual problem it would
prevent, let's back off that a bit! This should have the same effective
security properties for our case.

Note that the effect of this compatibility issue wasn't *weakening* the
policy; it was being *too* strict, by blocking the scripts and the
stylesheets. This is because `script_src_elem` was ignored, and
`script_src` was absent, so it fell back to `default_src none`.
2024-07-06 12:52:00 -07:00
5b2062754d swf_assets/show action to embed a canvas movie in a sandboxed iframe
Not using this on the item page preview yet, but we will!

I like this approach over e.g. a web component specifically for the
sandboxing: while I don't exactly *distrust* JS that we're loading from
Neopets.com, I don't like the idea of *any* part of the site that
executes arbitrary JS unsafely at runtime, even if we theoretically
trust where it theoretically came from. I don't want any failure
upstream to have effects on us!

I copied basically all of the JS from a related project
`impress-media-server` that I had spun up at one point, to investigate
similar embed techniques. Easy peasy drop-in-squeezy!
2024-07-03 19:50:41 -07:00
5905f4aed1 Delete more unused code
Just some routes and controllers that I think were at various points
serving as API endpoints, but no longer do I think!
2023-11-11 15:04:18 -08:00
010f64264f Replace swf_assets#index with item_appearances#index
Preparing a better endpoint for wardrobe-2020 to use! I deleted the
now-unused swf_assets#index endpoint, and replaced it with an
"appearances" concept that isn't exactly reflected in the database
models but is a _lot_ easier for clients to work with imo.

Note that this was a big part of the motivation for the recent
`manifest_url` work—in this draft, I'm probably gonna have the client
request the manifest, rather than use impress-2020's trick of caching
it in the database! There's a bit of a perf penalty, but I think that's
a simpler starting point, and I have a hunch I'll be able to make up
the perf difference once we have the impress-media-server managing more
of these responsibilities.
2023-11-11 07:14:48 -08:00
Matchu
e121d8bba2 Remove SWF conversion
We've already swapped out the backend for this stuff to Impress 2020, so the resque task and the broken image report UI aren't actually relevant anymore. Delete them!

This helps us delete Resque soon too.
2023-10-23 19:05:04 -07:00
Matchu
8ba07800d9 Fix item data not loading
Oops, finder options were removed! That's fine, the `:select` on here isn't useful anyway, and I'd rather just load everything and be simpler lol
2023-10-23 19:05:04 -07:00
b0cc4c2396 swf links 2015-05-03 16:57:42 -05:00
26ac3782ec move zones to database 2013-01-24 18:26:00 -06:00
bfd825d98e attempt to fix new species_support_ids format. sigh. 2013-01-23 00:25:09 -06:00
9701221035 wardrobe now considers item.species_support_ids when deciding compatibility
For example, the Meerca Maid Tray is a foreground item, so the SWF is marked
as compatible with all body types, but the item itself is clearly marked as
Meercas-only. items#show reflected this properly, but the swf_assets#index
call that the wardrobe uses ignored item.species_support_ids.

So, /bodies/:body_id/swf_assets.json?item_ids[]=... was deprecated in favor
of /pet_types/:pet_type_id/items/swf_assets.json?item_ids=[]..., which is
much like the former route but, before loading assets, also loads the pet
type and items, then filters the items by compatibility, then only loads
assets for the compatible items.
2013-01-02 23:15:32 -05:00
696b2aedaf give SWFs real, unique ID numbers
Lots of scary bugs were being caused by the fact that the possibly-duplicate Neopets ID
was being treated as an SWF's real primary key, meaning that a save meant for object swf
number 123 could be saved to biology swf number 123. Which is awful.

This update gives SWFs their own unique internal ID numbers. All external lookups still use
the remote ID and the type, meaning that the client side remains totally unchanged (phew).
However, all database relationships with SWFs use the new ID numbers, making everything
cleaner. Yay.

There are probably a few places where it would be appropriate to optimize certain lookups
that still depend on remote ID and type. Whatever. Today's goal was to remove crazy
glitches that have been floating around like mad. And I think that goal has been met.
2012-01-12 17:17:59 -06:00
6c9ddac8dd totally pro wardrobe image adapter, via konami 2011-05-22 16:30:02 -04:00
b13fd7ae99 moving toward s3 image storage 2011-05-20 19:19:14 -04:00
648649f5cc support special colors in the infinite closet 2011-05-02 18:07:56 -04:00
492841d9bc load happy pets for item db previews 2011-02-22 18:11:12 -05:00
99fb6b984f ensure that we're only returning item assets for items and biology assets for pet states 2010-11-25 21:33:34 -05:00
98d908d33c return nil, not 500, when missing certain swf_assets.json param 2010-11-15 16:04:54 -05:00
41aa9008fc remove indiscriminate asset caching 2010-11-15 15:58:16 -05:00
e40d4601d8 a functioning wardrobe 2010-10-10 22:18:42 -04:00
9671a02ecc zones are now a static resource, like species and color. database table remains for compatibility with main PHP app 2010-06-09 23:15:51 -04:00
a7ca99d7d8 cache swf asset JSON 2010-06-08 18:35:54 -04:00
37372544b0 alter item swf asset routes to allow for page caching 2010-06-08 18:26:42 -04:00
5e5032d671 bulk preloading item assets after 5 seconds, to be able to show reds more quickly 2010-06-07 16:33:43 -04:00
743ec4d910 restrict item swf assets by fitting body id 2010-05-20 21:30:12 -04:00
4604a412fd show biology assets on item preview from pet state 2010-05-20 21:16:43 -04:00
8411d4c64a swf asset json for pet types 2010-05-20 19:56:08 -04:00
230026597b groundwork for preview, swf asset and relationship model 2010-05-16 15:01:38 -04:00