| Re: [kapua-dev] Refactoring SSO |
|
Ok, now I understand. I was looking at the SSO implementation as something strictly related to the “host implementation”, given the diversity of
our web applications nature. It makes sense of course, but I think we should clarify something about the Patternfly console first. As of now, the Patternfly console is built upon a small HTTP server built on NodeJS, that serves as a REST API router as well. When we started its
implementation I thought it made sense given the abstraction given by the REST APIs, together with the development speed of a simple NodeJS application. However, gathering experience month after month on the project, I’m starting to think that having the Patternfly
console server written in such a different technology stack than the rest of the project isn’t a good thing, and your idea just confirms this: if we move everything SSO related to a separate project we couldn’t use it from a NodeJS app, leading us to duplicate
some code only for the console, and of course I strongly want to avoid something like that. So probably the Patternfly console project should be migrated to something like a lean Jetty server based implementation. It’s my time to ask: what
do you all think about this? :) -- Claudio Mezzasalma | Eurotech Da:
<kapua-dev-bounces@xxxxxxxxxxx> per conto di Jens Reimann <jreimann@xxxxxxxxxx> Currently the SSO stuff is distributed all over the code, in at least two projects. I would like to extract this in a set of modules, which are specific to SSO and allow using different implementations, if provided. This should isolate the different areas where SSO is used and provide a common function block which can then be re-used for REST, GWT and Patternfly. On Mon, May 8, 2017 at 6:03 PM, Mezzasalma, Claudio <Claudio.Mezzasalma@xxxxxxxxxxxx> wrote:
Jens Reimann |