about form

[ConvertFromOldNGs]

by allistar >> Thu, 15 Jan 2004 2:57:28 GMT

This is not very secure as all the user needs to do is change the application name in the ODBC settings and they can by-pass the security.

Regards,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

[ConvertFromOldNGs]

by dr >> Thu, 15 Jan 2004 21:37:31 GMT

I guess this isn't a problem if you have user codes dedicated to odbc access. However if user codes have both online (GUI app) and odbc access, i.e. you want to assign access rights by connection type as well as by user, then it appears you have a problem. How about restricting odbc access to a particular application type (e.g. Gui no forms), which you can interrogate in getAndValidateUser?



There is also an authentication method that can be called for each odbc access ... this suggests that Jade is clearly aware that a connection is from an odbc source, but doesn't expose this information.



On a bit of a tangent, if odbc access is provided as a messaging or data transfer interface (ad hoc queries for reporting implies a high level of trust in the users), then a relational view can restrict access only to a single agent class which has a local odbc authentication method implemented. Then, only the defined interface content is exposed through the agent class via virtual attributes and collections.



Cheers,

Rob

[ConvertFromOldNGs]

by Torrie >> Wed, 28 Jan 2004 8:56:32 GMT

From the documentation it appears that the getAndValidateUser method is not called for a ODBC application (just isUserValid.) You could check the application name in getAndValidateUser to see if a user can login with that application.

The ODBC connection is a fat client so you can also check the connection type. The INI file can be set to only allow certain applications to connect as a thin client connection so this can prevent users logging in to the ODBC application as a thin client.

There is still a loop hole in that a user could write a non jade application that uses the Jade API to connect as a fat client. I'm not sure if you can detect this.

[ConvertFromOldNGs]

by allistar >> Thu, 29 Jan 2004 3:10:11 GMT

Hi Torrie,
The problem is that the "user" in this case has complete access to the ini file, so any solution based on ini file settings will not work. Basically the user has complete control over the whole environment EXCEPT they can't access the cource code, so any solution must not rely on anything external the user has access to. When this issue becomes a priority I will see if it can be solved, I'll let the newsgroiup know either way.

Thanks,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------