Allow reading event.url/event.route in remote functions

[jhwz]

Describe the problem

I was reading the SvelteKit 3 migration guide and came across https://next.svelte.dev/docs/kit/migrating-to-sveltekit-3#Remote-functions-event.url-event.params-and-event.route-cannot-be-accessed-inside-queries

In our application we currently read these and pass through to activity logs (required for security auditing) in all remote functions so we have a record of which page/place they were invoked from. It’s purely metadata but would it be possible to still allow this going forward? Or is there a better workaround?

For context these are passed through to another API we run to be recorded (so we’re recording metadata against the API request. The built in instrumentation you have is great but doesn’t cover this case).

Describe the proposed solution

Either allow reading those properties again or support a workaround (maybe explicitly must use getRequestEvent).

Alternatives considered

Not support this

Importance

would make my life easier

Additional Information

There may be technical justification for this but if it’s just “users shouldn’t need to” hopefully this serves as a counter example !

Really appreciate all the work you’ve been doing recently - exciting times for Svelte ☺️

[teemingc]

I think one of the reasons we got rid of this is because the URL can be spoofed. The request pretty much tells the server where they’re calling the remote function from (don’t think the server can know otherwise). We wanted to discourage users from performing any URL-related checks since it wouldn’t be very trustworthy.

If you really wanted to access the URL on the server, you could always send it as one of the inputs to the remote function (though that has the same security implication as before with extra amounts of work).

This was never an issue with load functions or endpoints because the URL in those are just where they’re accessible from rather than the page the user is requesting them from.

[jhwz]

Yeah we definitely don't use it to make any security decisions - if malicious users want to spoof this that's fine in this scenario. This is about observability.

Completely understand that you want to prevent your users from making this mistake but it has been useful up until now :)

Sending it as an input to every remote function is impractical/tedious!

[teemingc]

Don’t know if a better solution might be to monkey patch fetch in the init hook or add a header to the request in the handleFetch hook that tracks this. You could then read this header in the handle hook or the remote function itself to log the client’s URL pathname.

Either way, sounds like something we should work on as part of observability and logging as a whole.

[david-plugge]

If the remote function requests go through the handle hook you should be able to set the url as a property on event.locals. I feel like it's the best place to build up generic request context for logging anyways, right?

[jhwz]

Yeah that may be the best work around here - it'll add another allocation to that code path but not the end of the world.

I feel like it's the best place to build up generic request context for logging anyways, right

Not in our case but generally yes

[elliott-with-the-longest-name-on-github]

Not in our case but generally yes

Why not in your case? handle is generally where any sort of "do this on every request"-esque logic needs to happen.

[jhwz]

For us:

• User needs some data, calls remote function
• Remote function may make one or more calls to an internal API (not all remote functions strictly do this)
• Those internal API calls go through a client object. That client uses getRequestEvent to attach the event.url/event.route to the API request
• The internal API keeps a log of all activity - when the calls come from our app which is fairly common we also record this metadata in the activity log. Useful for auditing purposes.

handle doesn't apply in this scenario. Essentially we have another layer of indirection between the user and the database whereas you're probably used to remote functions querying the database directly and being the right layer to record this "activity".