Best way to go about simple web app.

[enlightenedby42]

Ok, so I have had an internship with a very small software company for about 3 months now. Bear with me here, as I'm new to this stuff and mostly making sure there aren't huge fundamental flaws in my planning here. (this is very long, sorry, but a lot of background to describe the situation was needed)

Until recently, we've dealt exclusively with database heavy Windows apps for the HR departments of large trucking companies. Some of our customers are wanting simple web applications, and none of us (only 3 people) have ever done much of it before, so I've been tasked to find out the right/wrong ways to go about things. Haven't made it to web server design in school yet, so I'm flying by the seat of my pants here so again apologize for my n00b-ness.

Basically, the first thing we want to get out into the wild is a very, very simple web page that will allow a recruit to enter some information into a form, which will perform a parameterized query based on information gotten from the form, and display the recruit's job application status based on information existing in the database. The customers (and I) don't want to hassle with user registration, logging on and logging off, etc. This will be a one shot deal where you enter two numbers you are given into fields on a form, and information is displayed based on that. Also, when a user checks their status, the time and date they checked will be added to another table associated with that recruit's primary key so recruiters (and we) can get some feedback on whether its being used.

The thing about this is it needs to be designed in such a way that we can just give the code/html/whatever to a couple of customers so they can host it on their own existing servers and stick it on their own web sites (this is stuff our customers asked for by the way, personally I'm not sure if it will ever be used, but that's business I guess). Its just a free extra we're doing to a.) provide a requested feature to loyal long term customers for free and b.) break into more web applications, as it is clearly a necessity for the future

I'm most adept at coding in Java, and have a moderate bit of experience writing servlets to interact with Greasemonkey scripts via the xmlhttprequest. I'm no pro, but I basically understand what needs to happen on the database end of things (we use Firebird/Interbase stuff, and we've already done a good bit of proof of concept stuff as well as designed some general purpose DB wrapper and helper classes to handle queries and DB connections, so that's not the issue here so much).

So that's the background, and (finally) a few questions. First, is it a fundamentally horrible idea to just have a "one shot" approach where there are no logins or anything of that nature? Adding necessary registration beyond the candidate's already hefty paperwork requirements would probably cause people not to use it. My plan is basically to reuse our current working database wrappers and such, and make a fairly simple JSP that will dynamically display the needed information fetched from the database.

Are there any horrible security flaws with this? Our thinking is if it there aren't DB connections remaining open it SHOULD be more or less secure. Also, we are currently using Apache Tomcat (with Netbeans if that matters), and have found all sorts of issues with the server crashing in Netbeans and requiring reboots and stuff...we have tracked some of these issues to the open source JDBC driver (jaybird) we have to use for firebird, but is Tomcat as a whole a good tool to handle the back end stuff for something simple like this?

I apologize for the length of the post and probable lack of clarity, but any feedback from old hats at this stuff would be greatly appreciated.

 

[Dyslexic_Dog]

From a development point of view the "One Shot" method is nice, but what if you have people just changing a few things in their resume they are submitting? Now you have several resumes for the same person in the database. As a person looking for a job this is a easy way for you to get your name to stick out at people. This problem could also clog your database. I think you'd be better off with a simple sign up process integrated into the same form. Just get a email address and a password along with the resume. BTW I think java might be a bit of overkill. May want to stick with a more simple stable solution. LAMP is pretty solid for the most part. I'm pretty sure that PHP will connect to the database you are working with.

EDIT: I'm only a noob when it comes to programming so please take my opinion lightly. Others may chime in now that a discussion has been started.

 

[enlightenedby42]

From a development point of view the "One Shot" method is nice, but what if you have people just changing a few things in their resume they are submitting? Now you have several resumes for the same person in the database. As a person looking for a job this is a easy way for you to get your name to stick out at people. This problem could also clog your database. I think you'd be better off with a simple sign up process integrated into the same form. Just get a email address and a password along with the resume. BTW I think java might be a bit of overkill. May want to stick with a more simple stable solution. LAMP is pretty solid for the most part. I'm pretty sure that PHP will connect to the database you are working with.

Thank you for the response.

The thing is there will literally be no ability for people to make any changes. Most of our customers have already implemented ways of simply submitting online applications, so literally all that's being done here is a simple status check. A more robust app would be great and a nice experience, but that's what these people wanted I'm afraid.

About threading though, if you have a situation where small amounts of the same information are being pulled with no ability to modify, is there a chance that instance variables could overlap and somebody could get another person's information?

PHP is on my list of things, but I've already got a very rough version of this working in JSP and need to get this done in less time than I have to become proficient at another language.

 

[Dyslexic_Dog]

As far as I know the PHP variables are also based on the session so overlap shouldn't be an issue. Again I want to state that I'm fairly new to programming so don't take my word as law.

 

[enlightenedby42]

As far as I know the PHP variables are also based on the session so overlap shouldn't be an issue. Again I want to state that I'm fairly new to programming so don't take my word as law.

Thanks anyway bro. I say the exact same thing anytime I open my mouth around this forum.

I actually rather like being proven wrong at this point, as I will likely learn a far better way of doing something in the process.

 

[generelz]

Until recently, we've dealt exclusively with database heavy Windows apps for the HR departments of large trucking companies. Some of our customers are wanting simple web applications, and none of us (only 3 people) have ever done much of it before, so I've been tasked to find out the right/wrong ways to go about things. Haven't made it to web server design in school yet, so I'm flying by the seat of my pants here so again apologize for my n00b-ness.

What is a database heavy application? Is this a Windows program written in MFC/C# that interacts with a database via ADO.NET or some other persistence framework, or raw SQL?

Basically, the first thing we want to get out into the wild is a very, very simple web page that will allow a recruit to enter some information into a form, which will perform a parameterized query based on information gotten from the form, and display the recruit's job application status based on information existing in the database.

This sounds like a fairly sane and sound approach.

The customers (and I) don't want to hassle with user registration, logging on and logging off, etc. This will be a one shot deal where you enter two numbers you are given into fields on a form, and information is displayed based on that. Also, when a user checks their status, the time and date they checked will be added to another table associated with that recruit's primary key so recruiters (and we) can get some feedback on whether its being used.

This sounds good, I am going to assume that the information displayed is not personal information, which I assume because of the desire for no authentication. If there is personal data, I would strongly suggest adding a secure authentication mechanism.

The thing about this is it needs to be designed in such a way that we can just give the code/html/whatever to a couple of customers so they can host it on their own existing servers and stick it on their own web sites...

If you write a Java Servlet/JSP and bundle it as a WAR (Web Application aRchive), you and your customers will simply deploy that WAR in a servlet container such as Tomcat.

I'm most adept at coding in Java, and have a moderate bit of experience writing servlets to interact with Greasemonkey scripts via the xmlhttprequest. I'm no pro, but I basically understand what needs to happen on the database end of things (we use Firebird/Interbase stuff, and we've already done a good bit of proof of concept stuff as well as designed some general purpose DB wrapper and helper classes to handle queries and DB connections, so that's not the issue here so much).

IMO, Java is a good framework for building web applications of all sizes, simple to complex, and it's always best to get your feet wet on something simple like this. There is always the associated overhead that many people complain about, and lead others to go with other languages/frameworks because it seems too involved, for example Java and its associated frameworks and tools love XML configuration files which can be intimidating at first.

So that's the background, and (finally) a few questions. First, is it a fundamentally horrible idea to just have a "one shot" approach where there are no logins or anything of that nature? Adding necessary registration beyond the candidate's already hefty paperwork requirements would probably cause people not to use it. My plan is basically to reuse our current working database wrappers and such, and make a fairly simple JSP that will dynamically display the needed information fetched from the database.

No, as long as the user's personal information is protected then I don't think having a "one shot" approach is a bad idea at all.

You mention your current database wrappers, are you using JDBC, or some other persistence technology? My suggestion would be to model this as a simple MVC (Model View Controller) design, which you should be familiar with from your work on your other windows applications. Even for this simple project I would suggest trying to make a diagram or something of how the user will be directed and what happens in the "background".

I would suggest that in true MVC fashion you make the "view" component, the JSP, as dumb as possible. To do this you populate a Set or List of data objects into the request to make it available to the JSP, and then use JSTL or another expression language to display the necessary information. You should build this Set or List inside your Servlet code (the controller) by querying the model (in this case you may not even have a bona-fide model, it will essentially just be some database abstraction). Many first-timers are tempted to try and do the database access, etc. all in the JSP and this makes for a very convoluted design; indeed it is an anti-pattern of MVC design and could lead to trouble down the road if your customers start asking for more and you have to add more features.

Here might be a couple of good articles for you to review, if you're not familiar with MVC design:

http://wiki.apache.org/excalibur/SeparationOfConcerns
http://www.purpletech.com/articles/mvc/mvc-and-beyond.html

Are there any horrible security flaws with this? Our thinking is if it there aren't DB connections remaining open it SHOULD be more or less secure. Also, we are currently using Apache Tomcat (with Netbeans if that matters), and have found all sorts of issues with the server crashing in Netbeans and requiring reboots and stuff...we have tracked some of these issues to the open source JDBC driver (jaybird) we have to use for firebird, but is Tomcat as a whole a good tool to handle the back end stuff for something simple like this?

Security is more than just not leaving database connections open. In fact, leaving database connections open is completely orthogonal to the issue of security (IMO closing connections is more a matter of program correctness).

Issues you SHOULD be concerned about are the security of personal information. For example, is your application vulnerable to SQL injection attacks? Do you know how to avoid SQL injection the right way? If personal information is going to be transmitted, will it be secured via reliable encryption (i.e. SSL)? If personal information is passing between the web application and the database, is there the potential that it could be snooped because it is passing over a public network, and is this channel capable of being secured?

As far as Tomcat, IMO it is a very robust servlet container and application server, however it is only as stable as the code you put inside of it -- as you are experiencing. Generally I have found that when you are re-deploying code it is always better to shut tomcat down, delete the old WAR and deployment (and the temporary files), drop the new one in, and start tomcat. This, in my experience, is much cleaner than trying to undeploy, upload and redeploy.

Let me know if you have any more questions, I'd be happy to help if you didn't understand any of that.

 

[enlightenedby42]

Great stuff, first of all. Thanks for all the help.

What is a database heavy application? Is this a Windows program written in MFC/C# that interacts with a database via ADO.NET or some other persistence framework, or raw SQL?

I don't THINK there is a persistence framework. Almost all of the applications my company (a very small one..I'm an intern and also the third employee) has made have been written in Delphi pretty much exclusively to interact directly with databases. Parameterized query and update objects that store SQL statements and execute them directly in a data grid/data bound field in a Delphi Windows application as well as dump said data into Crystal Reports. I don't completely understand what a persistence framework is, but I THINK the answer is no..lol.

This sounds like a fairly sane and sound approach.


This sounds good, I am going to assume that the information displayed is not personal information, which I assume because of the desire for no authentication. If there is personal data, I would strongly suggest adding a secure authentication mechanism.

It is personal information...I'll explain. Basically, our main software package is one of the afore mentioned Delphi database apps for Windows. It is for the recruiting departments of trucking companies. It's a highly specific and powerful set of tools for managing any and every imaginable aspect of that. There are dozens and dozens of linked tables, the the "meat and potatoes" one stores the primary information for the candidates/employees of the company. Name, SSN, DOB, address, and a whole ton of internal stuff like drug test results, license class, and a bunch of foreign keys to tables of which recruiters handled the applicant, etc.

What this customer wants is a simple web app where an applicant can simply enter their SSN and a "pin number" (actually the unique key for their record in the DB) so they can check the status of their application from the company's web site. My current prototype simply gathers this information from an HTML form and passes it to a JSP that builds an SQL statement based on these parameters and queries the database for the driver's name, current employment status, and the e-mail address of the recruiter handing their case should they have any questions. So it is personal information, but not highly sensitive, and what is actually being pulled from the query wouldn't be very useful to anyone but the applicant I wouldn't imagine.

If you write a Java Servlet/JSP and bundle it as a WAR (Web Application aRchive), you and your customers will simply deploy that WAR in a servlet container such as Tomcat.

IMO, Java is a good framework for building web applications of all sizes, simple to complex, and it's always best to get your feet wet on something simple like this. There is always the associated overhead that many people complain about, and lead others to go with other languages/frameworks because it seems too involved, for example Java and its associated frameworks and tools love XML configuration files which can be intimidating at first.

I'm really liking it, myself. Learning curve is a little stiff with things, and you have to do things "Java's way", but you can do about anything you want really, most of which fairly painlessly.

No, as long as the user's personal information is protected then I don't think having a "one shot" approach is a bad idea at all.

You mention your current database wrappers, are you using JDBC, or some other persistence technology? My suggestion would be to model this as a simple MVC (Model View Controller) design, which you should be familiar with from your work on your other windows applications. Even for this simple project I would suggest trying to make a diagram or something of how the user will be directed and what happens in the "background".

I would suggest that in true MVC fashion you make the "view" component, the JSP, as dumb as possible. To do this you populate a Set or List of data objects into the request to make it available to the JSP, and then use JSTL or another expression language to display the necessary information. You should build this Set or List inside your Servlet code (the controller) by querying the model (in this case you may not even have a bona-fide model, it will essentially just be some database abstraction). Many first-timers are tempted to try and do the database access, etc. all in the JSP and this makes for a very convoluted design; indeed it is an anti-pattern of MVC design and could lead to trouble down the road if your customers start asking for more and you have to add more features.

Here might be a couple of good articles for you to review, if you're not familiar with MVC design:

http://wiki.apache.org/excalibur/SeparationOfConcerns
http://www.purpletech.com/articles/mvc/mvc-and-beyond.html

Ok, it is becoming clear to me that this is the thing I need to look at, and I fell into precisely the trap you described. Being really new at all this, my primary concern anytime I start working on something is, as silly as it sounds, "Can I talk to the database?". If I can't figure that out, I'm screwed, so I always tend to start there. So I just started making JSP's to do what I wanted because it was the path of least resistance. As I looked at it and the OOP principles I've had drilled into me started gnawing at me, I started wondering how one would separate the visualization and the business logic, and started looking at MVC in the "Teach yourself JSP in 24 hours" book from Sam's my boss had.

Basically, it is a framework for doing just that, right? As it stands I'm just using the JDBC driver for Firebird. We made a little db wrapper class that does little more than encapsulate some of the typing heavy tasks such as executing statements and establishing the actual database connection into simple functions that can be reused. Doesn't do anything special beyond that.

I basically just reused that wrapper because we've tested it pretty well so that the JSP code would be less messy. I just made a jsp for the login page (in retrospect there is no business logic there and I should probably just use regular HTML with some JS form validation tricks). The entires are passed into the formhandler.jsp page I made that takes those parameters, builds the query in a string buffer, executes it, and poops the results out on screen. Just describing it makes me cringe, as I am beginning to see that this is a very haphazard approach.

Security is more than just not leaving database connections open. In fact, leaving database connections open is completely orthogonal to the issue of security (IMO closing connections is more a matter of program correctness).

Issues you SHOULD be concerned about are the security of personal information. For example, is your application vulnerable to SQL injection attacks? Do you know how to avoid SQL injection the right way? If personal information is going to be transmitted, will it be secured via reliable encryption (i.e. SSL)? If personal information is passing between the web application and the database, is there the potential that it could be snooped because it is passing over a public network, and is this channel capable of being secured?

As far as Tomcat, IMO it is a very robust servlet container and application server, however it is only as stable as the code you put inside of it -- as you are experiencing. Generally I have found that when you are re-deploying code it is always better to shut tomcat down, delete the old WAR and deployment (and the temporary files), drop the new one in, and start tomcat. This, in my experience, is much cleaner than trying to undeploy, upload and redeploy.

Let me know if you have any more questions, I'd be happy to help if you didn't understand any of that.

I know what an injection attack is, but not precisely how to guard against one.

So basically, the form entries will be passed to an servlet running in the background somehow, which will dump them into garden variety collection objects that will be passed to a very dumb JSP that does little more than regurgitate said information?

I'm using Netbeans currently, can I just add the MVC aspect without completely starting the job over? I guess what's escaping me here is how one does the legwork in setting all that up mostly, and where what aspects of the code will go.

I am terribly sorry if my questions were vague, but in addition to clearly being a total n00b at this, I'm home and away from my code as well as the book I'm using.

Thanks again for your help!

 

[generelz]

Great stuff, first of all. Thanks for all the help.

You're welcome.

I don't THINK there is a persistence framework...

A persistence framework is essentially just a way to map objects and their relations to database tables. You probably have some sort of one and may not realize it. For any non-trivial application which interacts with a database, you generally always end up with some sort of persistence framework, even if it is ad-hoc, because it makes things a lot easier to deal with. Examples of persistence frameworks in the Java world would be Hibernate, EJB, TopLink, JDO, etc.

What this customer wants is a simple web app where an applicant can simply enter their SSN and a "pin number" (actually the unique key for their record in the DB) so they can check the status of their application from the company's web site.

I would consider my SSN one of the more sensitive pieces of my identity and would strongly suggest considering some sort of encryption at the very least.

My current prototype simply gathers this information from an HTML form and passes it to a JSP that builds an SQL statement based on these parameters and queries the database for the driver's name, current employment status, and the e-mail address of the recruiter handing their case should they have any questions. So it is personal information, but not highly sensitive, and what is actually being pulled from the query wouldn't be very useful to anyone but the applicant I wouldn't imagine.

How are you gathering the data from the form? Why are you building a SQL statement in a JSP? How are you building the SQL statement? Are you using parameter binding (the only truly effective way to avoid SQL injection attacks)? Do you know what parameter binding is? Judging by your comments later your application sounds like it is vulnerable to injection attacks.

Basically, it is a framework for doing just that, right?

Technically speaking MVC isn't as much as a framework as it is a design pattern, but I think you've got the idea.

I basically just reused that wrapper because we've tested it pretty well so that the JSP code would be less messy.

The JSP code should be dead simple. You should have two pages: one that is just a form for entering the required information, and another for displaying the data that was put into the request by the servlet. Your servlet should handle the business logic - connecting to the database, querying the database, and marshalling the results into a form the JSP expects.

formhandler.jsp page I made that takes those parameters, builds the query in a string buffer, executes it, and poops the results out on screen. Just describing it makes me cringe, as I am beginning to see that this is a very haphazard approach.

Then I guess I don't need to tell you that that is precisely the anti-pattern I described, as well as the fact that building a query by concatenation leaves you wide open to SQL injection attacks.

So basically, the form entries will be passed to an servlet running in the background somehow, which will dump them into garden variety collection objects that will be passed to a very dumb JSP that does little more than regurgitate said information?

Servlets don't run in the background. A servlet is just a very simple Java class that handles a request to a given URI determined by the configuration supplied to the Servlet container.

Your project should have one servlet, which encompasses the "controller" aspect of the MVC design. This is because it controls what the user sees next based on the input the user provides. The servlet provides you with two built-in ways to determine a very basic aspect of what the user input is: did they request data (generally a GET request, associated with the doGet method) or send data (generally a POST request, associated with the doPost method)?

Then the servlet interface methods provide you with some other important items: the request and the response. These are abstractions which allow you to work with the data sent to/from the user at a low level, but still in an object-oriented manner. The request is generally what you want to focus on here, you can ask it for more information, for example if the user supplied any URL parameters. For example, if I sent the URL: http://geminesis.net/myServlet?test=one&hello=two, I could say request.getParameter("test") and that would return the String "one". Similarly if form data is submitted via a POST request this data will be available from the request as well. Here is a good tutorial: http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/Servlet-Tutorial-Form-Data.html.

In your case, you will want to retrieve the two items of information that were submitted in the POST from your form page, and then make a SQL statement from that like you were doing in your JSP. Then you convert the results of the SQL statement into whatever form your JSP expects and stick those into the request, using setAttribute(), which allows you to store an object with a given "name".

Why stick them in the request? Isn't that where the data from the user came from? Well, what we do next is we will forward to the JSP - what this does is maintain that same request but asks the JSP to "do its thing".

Basically a JSP is a glorified servlet also, but it just has some nifty things built on top of it that make it more like a web page than a Java class. But fundamentally, a JSP is no more than a servlet whose doGet()/doPost() outputs the code you have entered into it! So, when we forward to the JSP, the request is still available along with that new item you put in there - and so you just access it using getAttribute and then display it however you like.

I guess what's escaping me here is how one does the legwork in setting all that up mostly, and where what aspects of the code will go.

The only thing left really is packaging and configuring Tomcat to deploy your Servlet, for which there are plenty of tutorials online. If you need any help with that, let me know and I can provide an example.