GeoMedia GIS Blog

"A picture is only worth a thousand words. A map may be worth a thousand numbers. But a GIS is worth a thousand tables."

Forcing a User to Login When Loading a Geoworkspace with an Oracle Connection

Posted by jeffhobbs on October 19, 2007

For those have connected to an MGE connection using an Oracle database, you’ll recognize this screenshot:

This comes up whenever you open/close a connection or open a geoworkspace. Personally, even though the MGE connection to an Oracle database is read-only, I think this is a valuable option. On a side note, on some machines you can save the user name and password into the ODBC DNS setup and this will eliminate the need for entering a password at this dialog. This can be done my just embedding the password with the user name like this:


Anyhow, I’ve always been surprised that Intergraph doesn’t force something similar for an Oracle Object Model connection…ESPECIALLY since this connection can be read/write! For those that don’t use Oracle with GeoMedia, by default GeoMedia will save the password (hidden) in the .gws. As a result, whenever you load the .gws, GeoMedia will connect to the Oracle database with the user name and password saved in the .gws. Yes, this is convenient. However, it’s not ideal from a security standpoint. Especially if you actually use unique logins in Oracle where User A may only have read/write to TABLE A while User B may have read-only to TABLE A. To be honest, even from a non-security standpoint, it’s still a bad idea. It’s fairly easy to make a mistake when you’re not paying attention or not expecting to be able to do something to the data.

So, there is a workaround to force a similar type of login restriction. This can be found in the "Working with GeoMedia Professional" PDF in Appendix B, page B-2. However I’ll post it here as well:

By default, GeoMedia stores the Oracle connection password in the GeoWorkspace. This is meant as a convenience and allows users to open existing GeoWorkspaces containing Oracle connections without having to re-enter connection passwords. However, this is a drawback to those users wanting higher levels of security. The option to turn off password persistence is in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\GDO\Oracle Object Read-Only\1.0\Store Password
HKEY_LOCAL_MACHINE\SOFTWARE\GDO\Oracle Object Read-Write\1.0\Store Password
The default setting is 1, which means that connection passwords will be stored. To force the user to enter a password for each Oracle connection, change the (default) setting to 0.
Password persistence is not an issue if you are using Windows Domain authentication for your connections.

When you set these registry entries, you get the following dialog when you open a .gws, or close/open the connection:

You notice that it just sets the password to a single asterisk. Usability-wise, it’s not as easy as the MGE dialog, but it’s not bad.

It’s interesting to note that you have the option to not save the password for the Oracle Object Model Read-Only data server, the Oracle Object Model Read-Write data server, or both. I would heavily recommend setting it for read-write. If you’re not concerned with other people having read-only access to your data, you can keep GeoMedia saving the user’s password for read-only connections. Incidentally, this is what I prefer.

Now, since I’m not a big fan of editing the registry manually, I wrote a small executable using AutoIt – a FANTASTIC piece of freeware that allows you to script many different mundane Windows tasks and save the scripts off as standalone executables. I’ve uploaded my registry modification script (both source and executable). You can download it from the left hand side of the screen or from here. The script will force the login screen for read-write connections but will store read-only connections. You can modify the source quite easily (just reference my comments in the script) if you’d like to force the login screen both both read-write and also read-only.

Sorry, the comment form is closed at this time.

%d bloggers like this: