Fork me on GitHub

is saying to trust client generated UUIDs? not sure if I understand it right but that sounds like a security disaster


why is it a disaster? can you describe one such disaster scenario? I've been using this strategy with success - just use UUID/SQUUID no need for tempid


a client could deliberate generate a uuid collision and overwrite something

Björn Ebbinghaus22:11:31

Obviously you check against that. Never trust any data from your client. But other than that..? What differs data like an email address from data like an id?


if you check against it, then you're not really using a uuid as a uuid. which is fine, but not what the passage in question is advocating


I'm not reading the book to say you just trust the UUID, but that you can generate the id without consulting with the backend first. So properly working code passes the checks without round trips, while there still are checks. As opposed to something like monotonically increasing ids where it's expected to get conflicts all the time, and pretty much nothing would pass without back and forth about the ids


I do not personally suggest avoiding tempids. I use them. I think they are an awesome idea and avoid all potential problems. That said, I included that section in the book because I had users whining about not wanting to use tempids…so, there ya go. The word “trust” is not meant to be a security statement, but in terms of uuid collisions, yes, you would need to make sure you’re using a GUUID to avoid those.


deliberate collisions are a security issue…but you can have that unrealated to tempids. A real production backend MUST ALWAYS verify that the UUID being written belongs to the user making the request. At that point if the users is hacking something they are only allowed to hack their own thing.


tempids make that whole process easier…because a tempid is a known new thing that can be assigned ownership.


whereas a uuid from the client has to be “existence” and “security” checked when you don’t use tempids (or a “new” marker)


tempids are great 🙂 these two lines next to each other • "The client can generate new IDs for entities without needing a server connection. • If you use GUUIDs, then they are globally unique. " read to me like it was implying that the client generated IDs can be assumed to be globally unique, which raised an eyebrow

Quentin Le Guennec13:11:11

Hello, if ::uism/target-actor contains a join to component User (`:query {:current-user/user (comp/get-query User)}`) and remote returned value {:current-user/user {…}} why doesn’t it get normalized according to the User component?

Quentin Le Guennec14:11:19

Ok, the solution was to also add ::m/returning User . Makes sense.

Quentin Le Guennec15:11:41

Is there a way to merge instead of replace when loading an edge from a remote?


Look at targeting in the book: there is append and prepend, BUT they auto-dedupe

Quentin Le Guennec16:11:10

I can’t find any mention of auto-dedupe in the book, but I achieved what I needed with a merge + sweep in the pre-merge hook


Search for the text “append-to”


it’s all over the place

Quentin Le Guennec07:12:22

Oh I see. Sorry but from my understanding “append-to” was about appending to a list of things. Thanks for the clarification.


What else would you want to append to other than a list?


Ah, you mean you want to merge. When you say append to me, I always think of lists of things, not maps.

Quentin Le Guennec08:12:21

Ok. So pre-merge is the right way to achieve this right?