A bit of a bizarre post since to_sgid has existed forever to generate signed global ids. Global IDs are probably one the most powerful and underrated features of Rails but regular global ids are only supposed to be used internally (e.g. job params) and never sent to the client.
If there’s a gotcha it’s that _signed_ global ids are only signed, not encrypted, and very few people seem to know about the optimised method (globalid::Locator.locate_many) for loading a batch of global ids
otikik 2 hours ago [-]
If you don't want invoice 22 to be shown by someone putting 22 on the url, you definetly need to enforce permissions on your app. The Global ID issue is tangential to that.
philipallstar 3 hours ago [-]
This title is odd, given the actual identified problem seems to be LLMs writing code.
claudiug 2 hours ago [-]
yeah, but if you say LLM is shit, and not rails... goodbye views :)
config_yml 2 hours ago [-]
> GIDs are not checked for authorization when doing the lookup - they are meant to be generated above the authorization layer, and to be consumed above the authorization layer
Then the problem with this post boils down to applying the authorization layer in any tool call, just like you do in controllers. Seems obvious?
jeremy_k 52 minutes ago [-]
Agreed. Seems like the author tried to get fancy using GIDs with LLMs to cut down on the logic in their tool calls and opened a can of worms.
rco8786 1 hours ago [-]
So....LLMs can hallucinate GIDs. I hope that everyone is aware of that.
kayodelycaon 3 hours ago [-]
Rails is a dangerous place to be throwing random data into APIs.
moondowner 3 hours ago [-]
Any popular Rails apps that use to_global_id?
rco8786 1 hours ago [-]
Almost any modern rails apps that have a job queue will use this at some point
GID's are great - i think the issue is with how they leveraged rubyLLM for something they should inherently not be using LLMs for.
> Remember that GIDs were made for facilitating ActiveJob serialization - they are a system-level facility, not a product-level facility.
I think this is somewhat obvious given the signature like gid://awesome-app/Post/32; there is no scoping to the user or account so it should be treated like a global lookup. If you need scoping to a user/account you can build that.
Honestly I think this is a matter of the author using poor design decisions and over leveraging LLMs. But this is not the fault of Rails, it is working as expected.
Be careful with LLMs!
Rendered at 16:16:19 GMT+0000 (Coordinated Universal Time) with Vercel.
If there’s a gotcha it’s that _signed_ global ids are only signed, not encrypted, and very few people seem to know about the optimised method (globalid::Locator.locate_many) for loading a batch of global ids
Then the problem with this post boils down to applying the authorization layer in any tool call, just like you do in controllers. Seems obvious?
GID's are great - i think the issue is with how they leveraged rubyLLM for something they should inherently not be using LLMs for.
> Remember that GIDs were made for facilitating ActiveJob serialization - they are a system-level facility, not a product-level facility.
I think this is somewhat obvious given the signature like gid://awesome-app/Post/32; there is no scoping to the user or account so it should be treated like a global lookup. If you need scoping to a user/account you can build that.
Honestly I think this is a matter of the author using poor design decisions and over leveraging LLMs. But this is not the fault of Rails, it is working as expected.
Be careful with LLMs!