is it possible to set the cookie name for csrf to ...
# talk-kratos
c
is it possible to set the cookie name for csrf to something predictable in Kratos? Sorry if this is a bit lame question. I can’t seem to find the information by searching here or in the docs. Basically, Kratos is setting the cookie named
csrf_token_82b119fa58a0a1cb6faa9738c1d0dbbf04fcc89a657b7beb31fcde400ced48ab
because that name is unpredictable, I’m passing on the entire set of cookies from my UI app to Kratos. Kratos happily ignores the other cookies that it’s not interested but it would be great if I can just sent what it needs. Is there any reason why the token has this randon suffix added to it? Why can’t it be like
ory_kratos_csrf
similar to
ory_kratos_session
?
n
I would love to know the answer for this too with the addition to the problem I have when Kratos and my apps are all hosted in Kubernetes. That seems to result in an infinite loop of 302 redirections due to the CSRF handling. The app never gets the right configuration to be allowed to complete login and registration flows when running in Kubernetes. Did you have this problem, @User or did you solve this?
c
@User while I don’t have 302 issue, I feel it would be more elegant to figure out the exact cookie needed by Kratos. I did run into 302 issue once when there were two cookies of
csrf_token_*
name because I did multiple kratos on localhost and each left one of these cookies.
👍 1
n
You are correct. Having a SINGLE cookie name would make issues a lot easier to track, whatever they are.
m
It may look random but it's not random
It's the sha256 hash of public url
So if you want to whitelist the cookie you can
c
Thanks @User that is indeed a good news! Is this documented anywhere? Also is this sha256 part of public api that developers can depend on, meaning, the maintainers wont change it adhoc without documenting them in the changelog?
m
I don't think it's documented anywhere. Right now it's an implementation detail so if you depend on the behavior it's possible that it may break in a future update. I'd create an issue to discuss since it looks like a legit use-case.