Return cookie auth for support packages offline first in flutter

[hortigado]

Hi, I'm currently using AppWrite with Brick in Flutter to support offline first, but the problem is that AppWrite doesn't return the cookie upon login. This forces me to modify the Flutter package to do so. Could you implement this so I don't have to keep modifying the package? Thanks

[hardikkaurani]

This seems like a very reasonable request, especially for Flutter apps built around offline-first synchronization patterns.

In many offline-first architectures, having access to the raw auth cookie/session token is important because synchronization layers, local persistence systems, and custom HTTP stacks often need direct control over authentication state rather than relying entirely on the SDK’s internal storage behavior.

If developers currently have to patch or fork the Flutter SDK just to expose cookie/session handling, that’s usually a sign the abstraction layer is hiding something that advanced use cases legitimately need access to.

This becomes especially relevant for:

• offline-first sync engines
• custom caching layers
• background sync workers
• multi-client persistence
• Brick integrations
• custom networking stacks
• hybrid local/remote auth flows

One possible approach could be:

• exposing session cookies through an optional advanced API
• adding a configurable auth persistence adapter
• allowing custom cookie/session storage handlers
• exposing lower-level HTTP auth hooks for advanced integrations

Something like:

final session = await account.createEmailPasswordSession(
  email: email,
  password: password,
);

final rawCookie = session.cookie;

or a pluggable persistence layer:

client.setSessionStorage(customStorageHandler);

would probably solve many offline-first integration issues without forcing developers to maintain SDK patches.

The important part is keeping the default developer experience simple while still allowing advanced control for teams building more complex sync architectures.

Related references:

• [Flutter Offline-First Architecture Guide](https://docs.flutter.dev/app-architecture/design-patterns/offline-first?utm_source=chatgpt.com)
• [Brick Offline First Docs](https://brickhub.dev/docs/offline-first/overview?utm_source=chatgpt.com)
• [Appwrite Flutter SDK Docs](https://appwrite.io/docs/references/cloud/client-flutter?utm_source=chatgpt.com)

Definitely feels like a valid DX improvement request for advanced Flutter/offline-first use cases.

[hortigado]

Hi, I currently solved it with ClientIo which allows access to cookieJar but I don't know how advisable it is.

 final uri = Uri.parse(client.endPoint);
        final cookies = await client.cookieJar.loadForRequest(uri);
        token = cookies.isEmpty ? null : '${cookies.lastOrNull?.name}=${cookies.lastOrNull?.value}';

[hardikkaurani]

Yeah, that workaround makes sense for now, and using ClientIO directly is probably acceptable in controlled environments where you understand the tradeoffs.

The main concern is less about correctness and more about relying on internal/session-storage behavior that may not be guaranteed as part of the public SDK contract long-term. If cookie handling changes internally in a future release, integrations built around direct cookieJar access could break unexpectedly.

That’s why an officially supported solution would still be valuable — especially for offline-first architectures where authentication state often needs to integrate with:

• sync queues
• local persistence layers
• background workers
• custom HTTP clients
• conflict resolution flows

Your workaround is definitely useful though, and it also helps demonstrate that there’s a real practical use case for exposing controlled session access officially rather than requiring developers to patch the SDK or depend on lower-level internals.