Removing cookie metaphors

Well. It would help a ton if we could at least *document* the metaphors. I don't believe that the name of the cookies are a burden, the lack of documentation / rationale for the cookies is.

I totally agree with the OP - the metaphors are a burden.

I tried to get some documentation available a while back, see glossary issue. But it isn't something that can be done on one's own.

I wrote Bakery to force us to finally integrate our usernames across *.drupal.org sites so that we would be in a position to move to better SSO tools in the future.

Most of that goal has been accomplished now. Groups (to pick the biggest subsite) is now using Bakery, and new sites tend to use it as a way to establish accounts consistently named with their Drupal.org counterparts.

I would really prefer to focus on better SSO tools to meet our long-term infrastructure needs.

@Damien The initial "rationale" for the naming of the cookies was that they happened to be the cookies available at the Chapter Three office during the redesign sprint. Later cookies were named by the contributor of the related code.

+1 to either documenting the cookie metaphors or converting the metaphors into self-explanatory names.

If we had a client-server diagram to show the sequence in the login process and the steps in master-slave communication, that would be great. Without that documentation, it makes the security model hard to grasp when reading the code. We are thrilled to be using the Bakery module on numerous client projects. But when we try to do a security audit to understand exactly how it works, the metaphors make it more challenging.

Don't get me wrong. We laughed out loud at all the cookie names. I personally don't believe there is such a thing as a "stroopwafel" cookie. ;-)

@DavidStrauss, are you putting your energy into a different SSO solution?

@brandonojc I've done work with other systems, but I haven't put any of that into d.o infrastructure. My primary motivation is around security. Bakery uses a shared secret which, while not a vulnerability in itself, makes the system easier to compromise when there's a vulnerability in other code.

The used cookies and their names have not been changed, even in the 3.0.x branch. What described here is still actual.