Impossible to reuse a login solution for several main apps

Classic Servoy
1

Issue:
New login paradigm: impossible to reuse a login solution/module for several main solutions/applications

Cause:
function application.getSolutionName() only returns login solution’s name

That function should instead return main solution/application’s name which would let programmers select the proper application context.

As with current login solution we do not know the application context, we are forced to hardcode the main application name into login solution: thus forcing to have a unique separate login solution for each application. That is BAD !

Thus we therefore claim the following feature:

The main application name should be transmitted as parameter to login solution’s onOpen method

For example: if user selected Solution MyCrm, the onOpen method of the associated login solution should receive ‘MyCrm’ among its parameters.

Other interesting params to pass to that onOpen method would be:

  • application.getSolutionRelease()
  • application.getApplicationType()

another goody we would burn a hand for:

  • pass a user(programmer) defined string as last optional parameter, which should be defined in main solution settings
2

Olivier,

The main shift in the new login mechanism is that a user now logs in in a server, not in an application.

A user first logs in with a server, and only then proceeds to the requested application (solution).
You can log in in a server and use all solutions available on that server without logging out first.

That means that the login solution should manage the server to login into without specific knowledge about the selected solution.

Note that when you do not set the solution title on the login solution, the title of the selected solution is shown.

Rob

3

rgansevles:
The main shift in the new login mechanism is that a user now logs in in a server, not in an application.

Yes we did remark that :D

Our issue has nothing to do with accessing multiple solution on the same server. It’s about integrating the new login concept in our development framework once and not having to recode it each time we install new customers on their own server. Please have a second look on our initial issue.

4

if your building your own framework for handling login, there really isn’t any need to use the new security model. You can still do everything you need the old way. Just set servoy.application_server.enhancedSecurity to FALSE on the servoy admin page.

5

@Scott
I wonder though when this would become deprecated and we all have to go this new way?

6

Thank you all,

First; Servoy documentation state: It is possible to disable Enhanced Security, but this is strongly discouraged.

To make it clear, we do have a full implementation of security in our application framework, compatible with older versions (up to 4.x) … and of course compatible with the needs of our corporate customers.

Security will become a more prominent argument these days (see Intel acquisition of Mc Affee). As Servoy has anticipated that trend and incorporated a more secure way to authenticate accesses, we do want to be compliant with the new features.

With current implementation, the lack of any means for the ‘login’ solution to ‘know’ which application is currently being accessed prevent us to incorporate it decently in our framework, and force us to modify each login solution by hand in order to ‘hardcode’ specific methods which will be in use for a specific installation, which is exactly what we want to eliminate.

Passing at least the name of the calling solution as parameter to the login solution will permit to enhance security and third-party framework integration. Adding an optional string parameter as asked in the last line of my request would be even more beneficial as it would let us a way to let customers decide and change their security policies without requiring new developments…

7

Olivier,

In 5.2.1, application.getSolutionName() will return the name of the main solution when running the login solution.

Rob