The URL injection in JS is what still puzzles me, since we’re not doing any HTML/JS preprocessing. 
  
Claudio Mezzasalma | Eurotech 
  
Da: 
<kapua-dev-bounces@xxxxxxxxxxx> per conto di Jens Reimann <jreimann@xxxxxxxxxx> 
Risposta: kapua developer discussions <kapua-dev@xxxxxxxxxxx> 
Data: martedì 9 maggio 2017 11:55 
A: kapua developer discussions <kapua-dev@xxxxxxxxxxx> 
Oggetto: Re: [kapua-dev] Refactoring SSO 
 
So in this case the WAR file already knows the URI to use?! It can either assemble it or get configured to point the JS code to a different URI. 
 
  
On Tue, May 9, 2017 at 11:34 AM, Mezzasalma, Claudio <Claudio.Mezzasalma@xxxxxxxxxxxx> wrote: 
Yes.
 
  
Are you suggesting to serve the REST APIs and the console from the same instance? I’m clearly missing something,
 but I can’t figure out what... 
  
Claudio Mezzasalma | Eurotech 
  
The frontend is served from the WAR file right? 
 
  
On Tue, May 9, 2017 at 11:30 AM, Mezzasalma, Claudio <Claudio.Mezzasalma@xxxxxxxxxxxx> wrote: 
Of course, but how to actually tell the frontend the correct URI to reach them? 
  
Claudio Mezzasalma | Eurotech 
  
Well the REST API can be accessible in any way, that is the purpose of it, right? 
 
So what configuration file are you referring to? 
 
  
On Tue, May 9, 2017 at 11:20 AM, Mezzasalma, Claudio <Claudio.Mezzasalma@xxxxxxxxxxxx> wrote: 
Since there is no server side rendered HTML I thought that using such a router was the easiest way to provide configurability
 of the REST APIs URL, since to the frontend would only need to know that they reside under /api while the NodeJS server would route it to the correct server reading its address from a configuration file. Reading the configuration file in the frontend to obtain
 such and address would have exposed all the configuration to the browser, so I discarded that approach. 
  
Claudio Mezzasalma | Eurotech 
  
The static files could all be served by a simple WAR file, the SSO stuff is subject to change and we could re-use the code there. And the REST API could be accessed directly?! 
 
So let's switch to Jetty (plain WAR-file). 
 
  
On Tue, May 9, 2017 at 10:54 AM, Mezzasalma, Claudio <Claudio.Mezzasalma@xxxxxxxxxxxx> wrote: 
It uses ExpressJS to provide three features: 
  
- Host an HTTP server that serves all the static files 
- Redirects every call to /api/* to the Kapua REST API, acting as a proxy 
- Acts as an entry point for SSO towards the configured identity provider 
  
You can look at the console-v2/server folder in the impl-consoleV2 branch 
  
Claudio Mezzasalma | Eurotech 
  
Sounds reasonable. But maybe you can give a bit more input on what the NodeJS part actually does. 
 
  
On Tue, May 9, 2017 at 10:34 AM, Mezzasalma, Claudio <Claudio.Mezzasalma@xxxxxxxxxxxx> wrote: 
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 
  
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: 
Hi Jens, 
  
I’m not sure I understand why you need such a refactoring. Could you please be a bit more specific on what you’re
 thinking about? 
  
Thanks! 
  
Claudio Mezzasalma | Eurotech 
  
I would like to start re-factoring the SSO implementation a little bit. Not changing anything from a logic/behavior point of view, but bringing together common SSO logic (as it exists
 now) into a kapua-sso project for simplifying development. 
 
Any objections? 
 
Cheers 
 
Jens 
 
 
--  
Jens Reimann 
Senior Software Engineer / EMEA ENG Middleware 
Werner-von-Siemens-Ring 14 
85630 Grasbrunn 
Germany 
phone: +49 89 2050 71286 
_____________________________________________________________________________ 
 
Red Hat GmbH, www.de.redhat.com, 
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, 
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
_______________________________________________ 
kapua-dev mailing list 
kapua-dev@xxxxxxxxxxx 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
https://dev.eclipse.org/mailman/listinfo/kapua-dev 
 
 
 
 
 
--  
Jens Reimann 
Senior Software Engineer / EMEA ENG Middleware 
Werner-von-Siemens-Ring 14 
85630 Grasbrunn 
Germany 
phone: +49 89 2050 71286 
_____________________________________________________________________________ 
 
Red Hat GmbH, www.de.redhat.com, 
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, 
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill 
 
 
 
 
 
 
 
 
_______________________________________________ 
kapua-dev mailing list 
kapua-dev@xxxxxxxxxxx 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
https://dev.eclipse.org/mailman/listinfo/kapua-dev 
 
 
 
 
 
--  
Jens Reimann 
Senior Software Engineer / EMEA ENG Middleware 
Werner-von-Siemens-Ring 14 
85630 Grasbrunn 
Germany 
phone: +49 89 2050 71286 
_____________________________________________________________________________ 
 
Red Hat GmbH, www.de.redhat.com, 
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, 
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill 
 
 
 
 
 
 
 
 
_______________________________________________ 
kapua-dev mailing list 
kapua-dev@xxxxxxxxxxx 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
https://dev.eclipse.org/mailman/listinfo/kapua-dev 
 
 
 
 
 
--  
Jens Reimann 
Senior Software Engineer / EMEA ENG Middleware 
Werner-von-Siemens-Ring 14 
85630 Grasbrunn 
Germany 
phone: +49 89 2050 71286 
_____________________________________________________________________________ 
 
Red Hat GmbH, www.de.redhat.com, 
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, 
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill 
 
 
 
 
 
 
 
 
_______________________________________________ 
kapua-dev mailing list 
kapua-dev@xxxxxxxxxxx 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
https://dev.eclipse.org/mailman/listinfo/kapua-dev 
 
 
 
 
 
--  
Jens Reimann 
Senior Software Engineer / EMEA ENG Middleware 
Werner-von-Siemens-Ring 14 
85630 Grasbrunn 
Germany 
phone: +49 89 2050 71286 
_____________________________________________________________________________ 
 
Red Hat GmbH, www.de.redhat.com, 
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, 
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill 
 
 
 
 
 
 
 
 
_______________________________________________ 
kapua-dev mailing list 
kapua-dev@xxxxxxxxxxx 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
https://dev.eclipse.org/mailman/listinfo/kapua-dev 
 
 
 
 
 
--  
Jens Reimann 
Senior Software Engineer / EMEA ENG Middleware 
Werner-von-Siemens-Ring 14 
85630 Grasbrunn 
Germany 
phone: +49 89 2050 71286 
_____________________________________________________________________________ 
 
Red Hat GmbH, www.de.redhat.com, 
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, 
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill 
 
 
 
 
 
 
 
 
_______________________________________________ 
kapua-dev mailing list 
kapua-dev@xxxxxxxxxxx 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
https://dev.eclipse.org/mailman/listinfo/kapua-dev 
 
 
 
 
 
--  
Jens Reimann 
Senior Software Engineer / EMEA ENG Middleware 
Werner-von-Siemens-Ring 14 
85630 Grasbrunn 
Germany 
phone: +49 89 2050 71286 
_____________________________________________________________________________ 
 
Red Hat GmbH, www.de.redhat.com, 
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, 
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill 
 
 
 
 
 |