635
Views
8
Comments
Solved
Share identifiers and session between Traditional and Responsive applications

Hello,

In our scenario (OS11), we have two applications: 1 is a Reactive application, the other one is a Traditional Web Application and there is a navigation between pages of the two applications. 


What we are trying to do, in the best possible way in terms of security, is to share the same session between the two applications. For instance, keep the session active, with the user logged between the navigation of both applications and synchronize that status in case of logging in/out.

We are considering an exchange of the user id or our session id (a customized id in our environment) between applications in some way (Encrypted parameter, cookies, session/client variables).

Any help will be appreciated.

Best regards.

Jose.


2021-08-12 11-00-27
Nordin Ahdi
 
MVP
Solution

Hi Jose,

Single-Sign On Between App Types can be enabled in Platform Server 11.8.0 and later:

When activated, this option lets users navigate between Traditional, Reactive Web Apps, and Mobile Apps distributed as Progressive Web Apps without having to sign in again. For example, if users sign in into a Traditional Web App, and then navigate to a Reactive Web App, they are signed in automatically in the Reactive Web App. To activate the Single Sign-On Between App Types setting, you need to have HTTPS enabled in the environment. 

Hope this helps!

Regards,

Nordin

UserImage.jpg
Jose Miguel Manjavacas

Nordin Ahdi wrote:

Hi Jose,

Single-Sign On Between App Types can be enabled in Platform Server 11.8.0 and later:

When activated, this option lets users navigate between Traditional, Reactive Web Apps, and Mobile Apps distributed as Progressive Web Apps without having to sign in again. For example, if users sign in into a Traditional Web App, and then navigate to a Reactive Web App, they are signed in automatically in the Reactive Web App. To activate the Single Sign-On Between App Types setting, you need to have HTTPS enabled in the environment. 

Hope this helps!

Regards,

Nordin

 

Hi, Nordin.

Thank you so much for sharing that configuration. Yesterday, we tried to do it in that way. 


First, we applied that security settings in our personal enviroment and it worked but now there is an internal problem with some system/internal calls, like the one that get the templates when we want to create a new application. We are getting a 403 error (forbidden). So, we cannot create new applications with that security settings.

In the log we are getting internal errors as this one:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Exception: HTTPS connection required for this web service
at ssServiceCenter.WebServices.Solutions.TestLogin(String inWSusername, String inWSpassword, String& outWSstatus)
   --- End of inner exception stack trace ---


RequestUrl: https://[env]/TemplateManager/rest/TemplateServices/Apps_ListTemplates (Method: GET) 

That error seems to be related to the TemplateManager module, wich cannot be modified by us.


In our enterprise  environment, we are having the same results. Internally we are getting some 403 errors (Forbidden) when we are consuming Service actions that were working befores the changes. Also, we have the same problem when we are trying to create new a application in dev environment, we are getting, in this case, an Unauthorized error (401). That, according to the Error log, is again related to the Template Manager module. 

In addition, the SSO is not working between applications of different types (Traditional/Reactive), even when they are sharing the same user provider.


Again, thank you a lot. I dont know if you have experienced similar behaviors after applying the security settings and if, maybe, we are missing any considerations, such as if is needed to launch a whole environment solution after the changes, etc ...

2019-10-24 08-26-27
Babu Basha

Hello Jose Manjavacas 

I would assume the platform already handles the scenario of logged in user session between traditional and reactive. I haven't tested this out but I would assume so, Are you having any issues that the session is not being shared while testing?


Thanks,

Babu

2026-02-26 06-29-24
Rahul
 
MVP

Hi Jose,

When you nevigate one screen to another screen within or other application you can take input parameter in Screen as a query string when you redirect you need to pass value in this parameter and you can encrypt this parameter and decrypt on other screen with orginal value.

Becasue Session are not available in Reactive app and can not share between other application.

parameter in URL with CryptoAPI

https://www.outsystems.com/forums/discussion/64311/change-parameter-in-url-with-cryptoapi-or-other-solution/


Hope this will help you.

Regards

Rahul

2018-08-15 15-09-17
Erdem Birinci

Hi Jose,
When you switch between them, Login session is dropping. My suggest is you should store your sessions in CS module. When you switch app, you can use login action for login.

2021-08-12 11-00-27
Nordin Ahdi
 
MVP
Solution

Hi Jose,

Single-Sign On Between App Types can be enabled in Platform Server 11.8.0 and later:

When activated, this option lets users navigate between Traditional, Reactive Web Apps, and Mobile Apps distributed as Progressive Web Apps without having to sign in again. For example, if users sign in into a Traditional Web App, and then navigate to a Reactive Web App, they are signed in automatically in the Reactive Web App. To activate the Single Sign-On Between App Types setting, you need to have HTTPS enabled in the environment. 

Hope this helps!

Regards,

Nordin

UserImage.jpg
Jose Miguel Manjavacas

Nordin Ahdi wrote:

Hi Jose,

Single-Sign On Between App Types can be enabled in Platform Server 11.8.0 and later:

When activated, this option lets users navigate between Traditional, Reactive Web Apps, and Mobile Apps distributed as Progressive Web Apps without having to sign in again. For example, if users sign in into a Traditional Web App, and then navigate to a Reactive Web App, they are signed in automatically in the Reactive Web App. To activate the Single Sign-On Between App Types setting, you need to have HTTPS enabled in the environment. 

Hope this helps!

Regards,

Nordin

 

Hi, Nordin.

Thank you so much for sharing that configuration. Yesterday, we tried to do it in that way. 


First, we applied that security settings in our personal enviroment and it worked but now there is an internal problem with some system/internal calls, like the one that get the templates when we want to create a new application. We are getting a 403 error (forbidden). So, we cannot create new applications with that security settings.

In the log we are getting internal errors as this one:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Exception: HTTPS connection required for this web service
at ssServiceCenter.WebServices.Solutions.TestLogin(String inWSusername, String inWSpassword, String& outWSstatus)
   --- End of inner exception stack trace ---


RequestUrl: https://[env]/TemplateManager/rest/TemplateServices/Apps_ListTemplates (Method: GET) 

That error seems to be related to the TemplateManager module, wich cannot be modified by us.


In our enterprise  environment, we are having the same results. Internally we are getting some 403 errors (Forbidden) when we are consuming Service actions that were working befores the changes. Also, we have the same problem when we are trying to create new a application in dev environment, we are getting, in this case, an Unauthorized error (401). That, according to the Error log, is again related to the Template Manager module. 

In addition, the SSO is not working between applications of different types (Traditional/Reactive), even when they are sharing the same user provider.


Again, thank you a lot. I dont know if you have experienced similar behaviors after applying the security settings and if, maybe, we are missing any considerations, such as if is needed to launch a whole environment solution after the changes, etc ...

2021-08-12 11-00-27
Nordin Ahdi
 
MVP

Hi Jose,

Only thing I can think of is that you do not have HTTPS enabled for your environment and that is a requirement for SSO between App Types to work properly. Can you make sure these security settings are enabled for your environment:

Regards,

Nordin

UserImage.jpg
Jose Miguel Manjavacas

Nordin Ahdi wrote:

Hi Jose,

Only thing I can think of is that you do not have HTTPS enabled for your environment and that is a requirement for SSO between App Types to work properly. Can you make sure these security settings are enabled for your environment:

Regards,

Nordin

 

 Hi, Nordin.

Thanks again.

It seems that the problem has been solved in our personal environment. I mean, now the SSO is working between a Traditional application and a Reactive application and now we can also create new applications without errors related to HTTPS resctrictions.

But we are getting again errors in our enterprise dev environment applying that configuration. And we cannot create new applications (401 Unauthorized) due to the fact that we are getting errors related to the new https configuration.


I don't know if in addition to applying the new security configuration from the service center, we must also launch a new solution from all the environment, seeing that modules not managed by us, such as TemplateManager, are also failing.


Best regards,

Jose.

2021-08-12 11-00-27
Nordin Ahdi
 
MVP

Hi Jose,

Normally, if the HTTPS security settings were already enabled and you have only enabled the SSO Between App Types setting in Service Center, it would suffice to just click the new Save and Apply Settings to the Factory button in order to apply the configuration change.

But since the warning message in LifeTime indicates that the HTTPS security settings were changed, it is better to be safe and create and publish an all components solution.

Hope this helps.

Regards,

Nordin


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.