• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to handle login credentials in a database login - logoff intensive environment

 
Magnus Herrström
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a database monitoring application where I read data from the database every n:th second and presents the result on a dashboard.

I want the user to log in once and behind the scenes the credentials will be used to log in and off the database when creating and dopping handles to the database.

My solution for handling the login credentials (below) does not feel stable so I wonder if there is a common practice for similar applications?

The login class...



And a call from a db class...



This is my first post on this forum so I may not have done everything by the book.

Cheers,
Magnus
 
Tim Holloway
Saloon Keeper
Posts: 18359
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Magnus.

Web applications actually get their database performance from doing precisely the opposite.

That is, rather than having the app create a connection, login, do work, and logout, the server (NOT the app) maintains a pool of already-open connections that are provided to the webapp(s) that need them. Creating a database network connection is an expensive task, so it's much more economical to create it once and re-use it over and over.

Of course, this means that all connections to the database have to be under the same userid and that therefore that database userid must have the lowest common denominator of all webapap users, so the database user rights have to be carefully determined and the webapp must enforce any finer-grained restrictions on who can do what to the database while using that connection. In extreme cases, it's even preferable that a second app be used when especially privileged operations need to be done.

This concept is not new to the web. I was in charge of a mainframe multi-user system that worked on a similar plan many, many years ago. It works perfectly well, at least as long as the application programmer can be trusted. Although admittedly that was somewhat easier to do back when programmers were considered as vital long-term corporate assets instead of as disposable cogs hired and fired over short terms. Or contracted out to people who had no vested interested in how the company fared beyond getting paid for the job.
 
Magnus Herrström
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Tim, and thanks for the input. But I guess I ended up in the wrong forum. I think my question would fit better under General Java since it is more of a Java coding question. Is it possible to move it?

//Magnus
 
Tim Holloway
Saloon Keeper
Posts: 18359
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think this is the right forum. Your question isn't really general Java, it's Java+databases, and this is the database forum.

I realized when looking at you code that actually this isn't a webapp, it's a stand-alone Java app. Didn't see the forest for the trees.

Normally when you're talking a stand-alone Java app, that's something that runs on the local user's desktop, so unless you're developing something like a GUI database editor program, you wouldn't be expecting to deal with more than one database userid, since staight-up Java apps are single-user programs.

You could, of course, setup a multi-user app, but to do that, you'd need some sort of client/server infrastructure to help the remote users interface to the central app (server). That's another topic, I think. Most commonly these days, people just do that kind of stuff as a webapp, and in fact, I developed one such app myself. I can log in, connect to any database, view tables and execute SQL statements from my web browser.

Because it's a lot of overhead, generally once you open a connection, you'd keep it open while you work (except on a webserver, where you don't want to keep unpooled connections open between requests). However, if you want a "prompt once, run multiple" option you can simply cache the credentials within the app and re-use them. Add a "change database' menu or button if you want the ability to switch to alternate databases within a session. And if you're paranoid, prompt for password before each reconnect, but make sure you wipe it from memory after doing so.
 
Magnus Herrström
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see your point Tim. I was a bit fuzzy in my question, but you are spot on. It is a stand-alone application that uses one Oracle user/pw to log in to the database which is the username and pw the user has to type in when he/she starts the app. The question is more in the line of if it is ok to store the credentials in the login object? Pass the un/pw to db objects? Public static fields? Leave the code as is?

The funny thing is that you thought it was a webapp. This application is about 2 years old, and at that time it was quite ok for it to be stand-alone, but now the need has shifted and I want to make it into a webapp. The problem is that I have no experience in that field . The application is built according to MVC so I wonder if it is possible to rewrite the view part and keep the rest.

I have googled 'converting from stand-alone to webapp' and similar but I haven't got any good hits. There are tools, but they are quite expensive. I think there even was possibility to do it in Eclipse, but that option seems not to be available in the latest version. Any hints on converting to webapp would be excellent

 
Tim Holloway
Saloon Keeper
Posts: 18359
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unfortunately, the architecture of desktop apps and webapps is so different that no automated tool can do a respectable job converting them. There are a number of MVC webapp frameworks, including JavaServer Faces, which is what I used for my database editor. I am also forum moderator here on the Ranch for JSF, incidentally.

The biggest reason why desktop and web apps don't convert too well is that desktop apps are wired for real-time event handling. The web (HTTP), is designed to process batches of data, instead. While you can make a webapp act very much like a desktop app - especially if you decorate it with lots of JavaScript and AJAX, the differences in how things get done keep the code transformation process from being simple.

As a general rule, you don't want to be keeping userids and passwords in a local file. If you do, however, you should encrypt them. You'll notice that a lot of web browsers do support local saving of credentials, but give you an option so that only credentials that you don't need to be really secure would be stored permanently.

I use the "password safe" utility to keep a centralized repository of critical credentials. The repository is encrypted, and can only be accessed through a master password, but it offers the advantage that it then posts credentials to the clipboard so that they're fed straight to the application and not publicly visible. The downside of this is that if you are dealing with multiple users, each one would require their own password safe. Or some similar product, such as the Norton password vault. Which makes support a little stickier.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic