Microservice may need access to satosa configuration

[rhoerbe]

Use Case: see issue #218 Or: a pair of request/response microservice need to share state via a cookie. Currently, the cookie name needs to be hard coded or configured twice.

Code Version

4.4.0

Expected Behavior

To provide the microservice with the backend entityID it needs to have access to the backend (or the complete proxy) configuration.

Current Behavior

Microservices get only their specific configuration

Possible Solution

Make configuration a singleton that can be imported on demand by any module.

[c00kiemon5ter]

I don't think issue #21 is the one you wanted to share. I'm curious to see what the use case actually is.

One thing you need to keep in mind is that Satosa does not differentiate how things happen based on the protocols (ie, the backends or frontends). Instead, it normalizes the different protocols in a common internal representation. If you request something specific to a protocol, then this is probably something that belongs to the respective backend or frontend.

---

a pair of request/response microservice need to share state via a cookie. Currently, the cookie name needs to be hard coded or configured twice.

Using the cookie is the only mechanism available (right now) to share data that will last throughout the flow. Each micro-service is responsible for the things it looks and puts into the state object (the cookie). You cannot go around this. The cookie name should be the micro-service name. This should be part of an API that imposes some rules on how one can store things into the state.

---

Make configuration a singleton that can be imported on demand by any module.

The singleton is one of the worst patterns. It is barely useful at all. It effectively works as global state, and we will try to have as little as possible of it.

---

Let me understand the use case, and we will see what the different approaches to this are.

[rhoerbe]

sorry, incomplete copy/paste. it is issue #218.

• Rainer

Am 2019-07-12 um 19:38 schrieb Ivan Kanakarakis [email protected]:

I don't think issue #21 https://github.com/IdentityPython/SATOSA/pull/21 is the one you wanted to share. I'm curious to see what the use case actually is.

One thing you need to keep in mind is that Satosa does not differentiate how things happen based on the protocols (ie, the backends or frontends). Instead, it normalizes the different protocols in a common internal representation. If you request something specific to a protocol, then this is probably something that belongs to the respective backend or frontend.

a pair of request/response microservice need to share state via a cookie. Currently, the cookie name needs to be hard coded or configured twice.

Using the cookie is the only mechanism available (right now) to share data that will last throughout the flow. Each micro-service is responsible for the things it looks and puts into the state object (the cookie). You cannot go around this. The cookie name should be the micro-service name. This should be part of an API that imposes some rules on how one can store things into the state.

Make configuration a singleton that can be imported on demand by any module.

The singleton is one of the worst patterns. It is barely useful at all. It effectively works as global state, and we will try to have as little as possible of it.

Let me understand the use case, and we will see what the different approaches to this are.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/IdentityPython/SATOSA/issues/255?email_source=notifications&email_token=ABBFUP3YTW6OD7D5JYOBYK3P7C6PXA5CNFSM4ICMYTMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ2M2ZQ#issuecomment-510971238, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBFUP4D6NMUCJN3EAAJSODP7C6PXANCNFSM4ICMYTMA.

[peppelinux]

in this place: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/base.py#L89 we could pass proxy config as argument or, better, call in the MS constructor a global function that does the following actions before returning satosa_config:

config_file = os.environ.get("SATOSA_CONFIG", "proxy_conf.yaml") satosa_config = SATOSAConfig(config_file)

This idea could introduce in addition also a refactor of this: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/wsgi.py#L12

moving it to a specialized function, importable everywhere, to get proxy configuration where needed. I think this is a better strategy to avoid passing configuration as argument in MS init and also better than leave that global vars there.

[ioparaskev]

maybe we should keep the conversation either here or in the mailing list (in the mailing list there is more discussion), otherwise it would be difficult to keep track of the conversation and reach a consensus