To issue a session cookie for local testing with Ory, you need to understand how Ory's session management works. For local development, you'll need to use the Ory Tunnel to ensure cookies work properly. ## Using Ory Tunnel for Local Development Ory uses cookies to manage sessions in browser applications, and these cookies must be set on the same domain as your application. For local development, you can use the Ory CLI Tunnel:

ory tunnel --dev --project $PROJECT_SLUG <http://localhost:3000>

This command opens port 4000 on your local machine and mirrors your Ory project APIs there. The

--dev

flag disables some security checks to make local development easier. [Local Development](https://www.ory.sh/docs/getting-started/local-development#local-development) ## Getting a Session Cookie via cURL After setting up the Ory Tunnel, you can obtain a session cookie by completing the login flow. Here's how to check a session using cURL:

curl '<http://localhost:4000/sessions/whoami>' \ -H 'Accept: application/json' \ -H 'Cookie: ory_kratos_session=YOUR_SESSION_COOKIE'

To initially get the session cookie, you need to: 1. Complete the login flow through the browser 2. Copy the

ory_kratos_session

cookie from your browser's developer tools 3. Use this cookie in your cURL or Postman requests [Using Ory Session Cookie](https://www.ory.sh/docs/kratos/session-management/overview#using-ory-session-cookie) ## Important Notes for Local Testing - Use either

localhost

or

127.0.0.1

consistently, not both, as cookies set on one won't be sent to the other - Make sure all your requests go to

<http://localhost:4000>

(or whatever port your Ory Tunnel is using) - Session cookies are automatically set by the browser after successful login - For Postman, you'll need to enable "Send cookies" in your request settings and manually add the cookie after obtaining it from a browser session Remember that Ory's security model requires the API and your application to be on the same domain for cookies to work properly, which is why the Ory Tunnel is necessary for local development.

Yes, it's possible to complete the login flow via a script or cURL without using a browser by using Ory's API flows specifically designed for non-browser clients. ## Using API Flows for Non-Browser Login Ory provides dedicated API flows for native applications, CLI tools, and other non-browser clients. These flows don't use redirects or cookies, making them suitable for scripting:

bash # 1. Initialize the login flow curl -X GET \     -H "Accept: application/json" \     https://$<http://PROJECT_SLUG.projects.oryapis.com/self-service/login/api|PROJECT_SLUG.projects.oryapis.com/self-service/login/api> | jq

This returns a flow object with an ID and action URL:

bash # 2. Complete the login flow with password method actionUrl=$(curl -s -X GET -H "Accept: application/json" \   "https://$<http://PROJECT_SLUG.projects.oryapis.com/self-service/login/api|PROJECT_SLUG.projects.oryapis.com/self-service/login/api>" \   | jq -r '.ui.action')  curl -s -X POST -H "Accept: application/json" -H "Content-Type: application/json" \   -d '{"identifier": "<mailto:user@example.com|user@example.com>", "password": "yourpassword", "method": "password"}' \   "$actionUrl" | jq

Upon successful login, you'll receive a JSON response containing a session token (not a cookie):

json {   "session_token": "oFZzgLpsacUpUy2cvQPtrGa2046WcXCR",   "session": {     "id": "8f660ce3-69ec-4aeb-9fda-f9230dc3243f",     "active": true,     /* additional session data */   } }

You can then use this session token for authentication in subsequent requests:

bash curl -s -H "Authorization: Bearer YOUR_SESSION_TOKEN" \   https://$<http://PROJECT_SLUG.projects.oryapis.com/sessions/whoami|PROJECT_SLUG.projects.oryapis.com/sessions/whoami> | jq

[Self-service flows for API clients](https://www.ory.sh/docs/kratos/self-service/flows/user-login#api-clients) ## Important Notes 1. API flows return session tokens instead of cookies 2. Never use API flows for browser-based applications as this opens security vulnerabilities 3. The flow doesn't involve redirects, making it suitable for automation 4. You must handle the token storage and management in your script This approach is ideal for CLI tools, native mobile apps, IoT devices, or any non-browser client that needs to authenticate with Ory. Would you like more details on any specific part of this process?

You're right to point out the distinction between session tokens and session cookies in Ory. Let me clarify how these work and address your specific question. ## Session Tokens vs. Session Cookies Ory intentionally separates these authentication methods for security reasons: - Session Cookies: Used for browser-based applications - Session Tokens: Used for non-browser applications (mobile, CLI, etc.) As mentioned in the documentation, "For security reasons, you can't break the isolation between cookies and session tokens" [Ory Session Management Overview](https://www.ory.sh/docs/kratos/session-management/overview). ## Can You Get a Session Cookie Without a Browser? The short answer is no - you cannot directly obtain a session cookie without a browser interaction. This is by design in Ory's security model. Session cookies are specifically designed for browser-based flows and include security features like SameSite attributes and HttpOnly flags that require a browser context. When using the API-based flows, Ory will always return a session token rather than a cookie. This is because: 1. Cookies are browser-specific mechanisms 2. The security model for cookies relies on browser enforcement 3. API flows are designed for non-browser clients that can't properly handle cookies ## Alternative Approaches If you specifically need to work with session cookies for testing purposes, you have a few options: 1. Use a headless browser: Tools like Puppeteer or Selenium can automate browser interactions and capture cookies. 2. JWT Conversion: For cross-origin requests where cookies are problematic, you can convert a session to a JWT:

bash curl -X GET \   -H "Authorization: Bearer YOUR_SESSION_TOKEN" \   "https://$<http://PROJECT_SLUG.projects.oryapis.com/sessions/whoami?tokenize_as=your_jwt_template|PROJECT_SLUG.projects.oryapis.com/sessions/whoami?tokenize_as=your_jwt_template>"

This returns the session with an additional

tokenized

field containing a JWT that can be used for authentication. [Convert Ory Sessions to JSON Web Tokens](https://www.ory.sh/docs/identities/session-to-jwt-cors) 3. Server-side proxy: Have your server obtain the session token, then use it to make authenticated requests to Ory on behalf of your client. Remember that the separation between cookies and tokens is a security feature, not a limitation. Each is optimized for different client types and use cases. Does one of these alternative approaches work for your testing scenario?

New message text here

Based on the knowledge sources, the Ory Permission Language (OPL) files use the

.ts

extension, as they are defined as a subset of TypeScript. This can be seen in several examples from the documentation: 1. In the CLI documentation for updating OPL files, the example shows a file path with a

.ts

extension:

$ ory update opl --file /path/to/namespace_config.ts

[ory update opl](https://www.ory.sh/docs/cli/ory-update-opl#ory-update-opl) 2. When configuring permissions via GitOps, the documentation shows:

ory update opl --file permissions.ts

[Manage Ory Network configuration in git](https://www.ory.sh/docs/guides/gitops) 3. In the Ory Console example, the file is named `namespaces.keto.ts`:

namespaces.keto.ts

[Get started with Ory Permissions](https://www.ory.sh/docs/guides/permissions/overview#example) The

.ts

extension is appropriate since the Ory Permission Language is specifically designed as a subset of TypeScript, allowing you to leverage TypeScript's type checking and editor support while writing your permission rules.