Emile Cormier

> Another approach I'm toying with in my mind is that the error URIs prescribe how the client should react I gave this some more thought, and this is not...

Here is a big brain dump of me stepping back and looking at the big picture. I do not claim to be an expert in any of the computing fields...

> > we definitely should use a consistent wording ... and "request" doesn't IMO ... > > Why not "request"? It is a message originated by the client for which...

> Regarding error URI, I still prefer `wamp.error.too_many_requests` over others, even over `wamp.error.limit_exceeded `for a few reasons: > > From its name it is clear even without details that I...

> Rgd auth flow: well, a router could return the wamp.error.authentication_denied and that's it. But maybe having a wamp.error.too_many_requests there would be nice too.... The idea is for a client...

> The idea is for a client app to know when to display "Too many login attempts" instead of "Incorrect username and/or password". If wamp.error.authentication_denied is used for both, then...

> Session IDs might as well be cryptographically-random because those generators are fast now. (Common advice from cryptographers -- which I am not -- is "just use /dev/urandom" still, I...

What I'd like to know is what an attacker could possibly do with a leaked session ID. If there's no possible harm, then I would prefer to leave session IDs...

I've decided to blank out session IDs completely in the logs by default, and the user can supply their own obfuscator function to scramble the session IDs in the logs...

> We should also consider including a summary of which message options that ~leak~ expose the session ID, as well as authentication information. - `HELLO.Details`: `authid`, `authextra` - `WELCOME.Details`: `authid`,...