--
You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiali-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/fdec5f0f-8cc4-4f4a-ad6a-c586bfd2b91cn%40googlegroups.com.
The only reason is because Kiali is stateless and there is no back-end storage.
The UI does nothing with it. The UI even can't read the token because it's stored in an HTTP-Only cookie. It's there only for the back-end to read it on subsequent requests.
My understanding is that using UUIDs, or any other kind of ID will require back-end storage to save the mapping of UUID-to-tokens.
Memory is the only storage we have available. In a non-kubernetes environment, using memory as storage is OK. However, in Kubernetes workloads are ephemeral which means that memory storage is unreliable.
That said, if you have a fully state-less way of using UUIDs and still have a way to retrieve the associated serviceaccount token for subsequent requests, you are free to use UUIDs as sessionId.
The only reason is because Kiali is stateless and there is no back-end storage.
The UI does nothing with it. The UI even can't read the token because it's stored in an HTTP-Only cookie. It's there only for the back-end to read it on subsequent requests.
Got it, so the UI doesn't care about the information, only the backend?
My understanding is that using UUIDs, or any other kind of ID will require back-end storage to save the mapping of UUID-to-tokens.
Memory is the only storage we have available. In a non-kubernetes environment, using memory as storage is OK. However, in Kubernetes workloads are ephemeral which means that memory storage is unreliable.
That said, if you have a fully state-less way of using UUIDs and still have a way to retrieve the associated serviceaccount token for subsequent requests, you are free to use UUIDs as sessionId.
I see. In this case the only token used is the one coming in from the request on each each request. My plan is to update business.Get(token) --> business.Get(api.AuthInfo) to give each request the ability to set a token and impersonation headers from the reverse proxy. So if we're setting the auth info on each request, there's no need for any kind of session info, right?
--ThanksMarc
You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiali-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/b3e7b133-c7c7-4105-84b6-217f792e69c2n%40googlegroups.com.
Yes, the UI doesn't care.
However, there is an endpoint (/api/auth/info) that the UI calls to get the username. The back-end tries to extract the username from the token.
Strictly speaking, the UI doesn't care where the username came from. Yet, that info is related to the token. It's something to keep in mind when changing the auth methods.
Right! If the reverse proxy is providing the needed data, no need for session info. Just use the data in the headers.