Hello all!
I would like to start using Squeak as the glue that connects different applications on my machine(s). I've decided that the best way to do this without having to deal with too much Unixy mambo-jumbo is to build little web apis and have the servers run in Squeak. That said, I've run into a problem: WebServer currently has no way to configure itself for CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. Usually this wouldn't be an issue -- I could add the appropriate headers on my Response objects as needed manually. However, WebServer opaquely handles certain requests itself, specifically the OPTIONS request, which is used as a preflight fetch.
A clear example of a use case is the one I'm building now: a bookmarklet https://en.wikipedia.org/wiki/Bookmarklet that saves some info about the current page I'm on, and then sends that info to my little Squeak mini web server locally on the same machine. This ends up being a cross-origin request, however, and as it stands WebServer cannot deal with it (throws a CORS error on the client side).
So, two questions. First: has anyone already dealt with this and am I missing some simple technique/package? Second: if not, what do we think is the best move here? Should we create something like a CrossOriginPolicy object, have a default instance present on WebServer that does what it currently does (which is nothing), but make it configurable? If the latter seems reasonable then I can take it on.
Thanks!
There's some small help in Seaside for this, at least as best I understand it. You can add to the request response header so as to insert 'Access-Control-Allow-Origin *', for example. Some more formal support was added in v3.4.6 late 2021 I think.
On 2023-08-24, at 7:20 AM, Eric Gade eric.gade@gmail.com wrote:
Hello all!
I would like to start using Squeak as the glue that connects different applications on my machine(s). I've decided that the best way to do this without having to deal with too much Unixy mambo-jumbo is to build little web apis and have the servers run in Squeak. That said, I've run into a problem: WebServer currently has no way to configure itself for CORS. Usually this wouldn't be an issue -- I could add the appropriate headers on my Response objects as needed manually. However, WebServer opaquely handles certain requests itself, specifically the OPTIONS request, which is used as a preflight fetch.
A clear example of a use case is the one I'm building now: a bookmarklet that saves some info about the current page I'm on, and then sends that info to my little Squeak mini web server locally on the same machine. This ends up being a cross-origin request, however, and as it stands WebServer cannot deal with it (throws a CORS error on the client side).
So, two questions. First: has anyone already dealt with this and am I missing some simple technique/package? Second: if not, what do we think is the best move here? Should we create something like a CrossOriginPolicy object, have a default instance present on WebServer that does what it currently does (which is nothing), but make it configurable? If the latter seems reasonable then I can take it on.
Thanks!
-- Eric
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
Hi Eric,
I don't know the answer to the CORS question, but I've been working deeply with WebServer over the summer, and also noticed that #dispatchRequest:url: was rather rigid. At one point, I faced an issue where I could no longer bear the forcing to lowercase all service urls. I ended up overriding that method (along with #addService:action:methods: and #removeService:) with identical versions other than removing the "asLowercase". Subclassing gave me an open-canvas that liberated my mind from the constraints and limitations of WebServer, and allowing WebServer's raw simplicity and direct approach to remain "unspoiled" by my new abstractions.
Regards, Chris
On Thu, Aug 24, 2023 at 9:21 AM Eric Gade eric.gade@gmail.com wrote:
Hello all!
I would like to start using Squeak as the glue that connects different applications on my machine(s). I've decided that the best way to do this without having to deal with too much Unixy mambo-jumbo is to build little web apis and have the servers run in Squeak. That said, I've run into a problem: WebServer currently has no way to configure itself for CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. Usually this wouldn't be an issue -- I could add the appropriate headers on my Response objects as needed manually. However, WebServer opaquely handles certain requests itself, specifically the OPTIONS request, which is used as a preflight fetch.
A clear example of a use case is the one I'm building now: a bookmarklet https://en.wikipedia.org/wiki/Bookmarklet that saves some info about the current page I'm on, and then sends that info to my little Squeak mini web server locally on the same machine. This ends up being a cross-origin request, however, and as it stands WebServer cannot deal with it (throws a CORS error on the client side).
So, two questions. First: has anyone already dealt with this and am I missing some simple technique/package? Second: if not, what do we think is the best move here? Should we create something like a CrossOriginPolicy object, have a default instance present on WebServer that does what it currently does (which is nothing), but make it configurable? If the latter seems reasonable then I can take it on.
Thanks!
-- Eric
squeak-dev@lists.squeakfoundation.org