Is there any way how I could set up a cookie / ses...
# talk-kratos
w
Is there any way how I could set up a cookie / session token which is always valid? So my use case is testing my backend. Manually and ideally also in automated tests. And it's not so much fun to log in and obtain some valid cookie so I can make some test requests against my backend. For tests it is even more difficult. Currently in the tests I mock Ory, but it would be great to also have some some integration tests with ory running. I tried with setting up ory kratos in docker and adding some data to the database. While I can do some basic stuff with this like setting up an identity, I couldn't figure out how to set it up so it will always accept an cookie. I kind of assuming this is not possible right now. So is something like this planned or what would be your suggestion with dealing with these sort of issues?
h
Hey Leon, most e2e test frameworks have ways of authenticating users - for example playwright: https://playwright.dev/docs/auth
w
@high-optician-2097 I think this isn't quite what I'm asking for. This is for testing something with a frontend, but I'm talking about my backend. So to give more context: I have a backend with some routes. Say POST /myRessource. The endpoint is later called from some Frontend, for instance a SPA. It will check for cookies and forward them to Ory to get the session and check if the user is authenticated. So theoretically I could use my frontend to get some sample token or I could use something like curl directly in my tests or for manual testing against ory directly. But this ist just a lot of effort. For instance at the moment my frontend isn't even running. I just wrote a new rest endpoint and want to test it quickly with Postman. And for this I have to spin up my frontend, do a login, copy the cookie from the browser, paste it into postman. That's really a lot of effort and kind of demotivating. What I instead would prefer is to have some sample cookie or token, which just always works. Obviously only for my test ory kratos instance. So whenever I do a request for my test user with cookie X Ory will just accept it. As I said this also would make some integration tests easier or even e2e backend tests. While it is very sensible to test against an actual running ory kratos service, I don't need to test login. That's not the job of my backend. My backend just needs to verify logged in user. So I would like to avoid any complex setup to get data of a logged in user in the first place. Of course for my frontend the story is different. There I actually have the login fields and it makes totally sense to tests them there. And even for parts of my frontend, where I don't need it, it's much easier to recieve a valid cookie, because my frontend contains the functionality for it in contrast to my backend. I hope I clarified why I think this feature is useful πŸ™‚
h
I see, that makes a lot of sense to me. Unfortunately, such a feature does not exist yet. If you want, check here how we are doing this in our tests: https://github.com/ory/kratos/blob/master/examples/go/pkg/resources.go#L23
w
Would you think opening up a features request would make sense for this? I would suggest an admin endpoint where you can set up a test account and pass: Identity Information (such as username, password) and a fixed cookie and session token One could think about different methods how ory kratos could prohibit such a usage in production and allow it only for testing / debugging purposes. First thing that comes to mind is that ory kratos serves at two endpoints one for production and one for testing. And only the latter allows setting up such things.
One question regarding your test setup: How do you ensure that the user is deleted again afterwards? Are you just using some in memory database docker setup of ory kratos for this?
Ah sorry I just saw there is actually a config in the subfolder for this. So yes you seem to be using an in memory database for this πŸ˜„
h
πŸ‘ Regarding the feature request: I’m not sure if we would implement such a thing, just because it’s so easy to misuse. But at the same time, it would make developer lives so much easier
w
Yeah I can definitly see the problem. I'll open up a feature request sometimes soon and maybe some people have ideas how to implement this and make it hard to misuse.
h
πŸ‘