As you get more serious about Java EE 7 development, the logical first step is to upgrade to Java 1.7 everywhere. You must decide between the 32-bit and 64-bit versions, with an eye towards what operating system you have and what IDE and tools you will be using. The 32-bit version is a safer bet if you still use older tools, but I’d like to be 64-bit everywhere.
Download the JDK here: http://www.oracle.com/technetwork/java/javase/downloads/index.html. Install it, and set its /bin in the PATH environment variable. Also set the JAVA_HOME to this installation’s root directory, and the JRE_HOME to its /jre directory (which is the server JRE). You might have also installed a public JRE; note that this is a client JRE used by web browsers and HotSpot.
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
If you want to use the GlassFish application server in your development, you should also download the Java EE 7 SDK (without JDK) from http://www.oracle.com/technetwork/java/javaee/downloads/index.html. When you install it, you might get this error:
This application needs version 1.6 or higher of the Java 2 Runitme Environment.
If the required Java 2 Runtime Environment is not installed, you can download it from the following website: http://java.sun.com/j2se.
Or if you already have the required Java 2 Runtime Environment installed, try rerunning this application with the following usage:
"java_ee_sdk-7-windows.exe -j <JAVA installation directory>"
Never mind that I already have JAVA_HOME set in environment variables, or that calling “java” on the commandline is successful, this error does not make sense at all. But install with the commandline suggestion.
Buying an SSL certificate should not be an overly emotional event. The easiest approach is to understand what the certificate will do for you: (1) encrypt your session, and (2) deliver a level of trust to clients.
The most important considerations should focus on how well the certificate protects your data (is it 128- versus 256-bit encryption) and what will be protected (single domains versus subdomains or multiple domains). I almost always choose 256-bit wildcard certificates. They are a little more expensive per annum, but they provide better flexibility should things change on your domain.
The second thing you should consider is the kind of certificate:
* Domain validation (DV) = validate just the domain registration is owned by the applicant.
* Organization validation (OV) = validate business information as well.
* Extended validation (EV) = validate business extensively, not usually for personal use.
I almost always go with a DV SSL for most purposes, the default for many SSL purchases. You might see a whole lot more features offered as part of your certificate, but I haven’t found much use for them, except to give the client additional trust in your website. There is insurance or warranty levels, multi-year deals, etc.
But of particular interest are mobile-compatible certificates, although none of the SSLs I’ve used to date have failed to work on mobile devices. Also, the so-called “green bar” certificates which offer the highest level of trust, seem unnecessary to me.
So for most of us, a 256-bit DV wildcard single-year SSL certificate gets the job done. Renewals are usually sold at discount. Most vendors also offer graphics and realtime validation of the certificate when a protected page is loaded. A great perk, but you shouldn’t have to pay additionally for it.
Webapps run on the Internet over HTTP, which relies on TCP/IP. But TCP/IP is inherently insecure. To secure IP, Internet Protocol Security (IPSec) is the answer, for encrypting network communications at the Internet layer (Internet Protocol suite).
A complete solution however also requires a firewall to control access, and vigilant patching of operating systems and dependent applications/libraries.
IPSec uses two separate protocols to secure data transmission:
(1) Authentication Header (AH) for authentication and integrity verifcation of packets, and
(2) Encapsulating Security Payload (ESP) for encryption services.
IPSec helps guard against attacks such as:
- Eavesdropping (reading data in transit)
- Address spoofing (rerouting data in transit)
- Man-in-the-middle attacks (modifying data in transit)
- Denial of service (DOS) attacks = flooding a system with unnecessary traffic, overwhelming it so it is unresponsive.
- Sniffer attacks.
Independent contractors, especially web developers, have most likely experienced this situation: somebody sends you a one-paragraph description of a webapp they’d like and ask you how much it will cost, and when you can deliver it.
An application called SKIVI, designed to help independent contractors run their
businesses. Users can self-register accounts for their business, and when logged in,
can manage their contact and login information. This first module should also be
secure and look nice, using the latest web technologies.
That is a typical description, and in fact a real one. You really cannot answer any of the questions yet. In fact, the first question to answer is whether you can do such a project, whether you have the skills and time for it [YES]. And before you answer any further questions, you need a more specific description similar to what I described in http://blog.strive-ltd.com/2012/11/how-webapps-are-made-pt-2/.
So I’ll expand the given description and develop a full-blown application in PHP using the Symfony2 framework using the NetBeans IDE. Along the way, I’ll answer those initial questions.
I’ve never been a big fan of NetBeans IDE for Java development, often defaulting to the Eclipse IDE instead. But I decided to give NetBeans another whirl and see if it works better than several other PHP IDEs and text editors that I tried. Surprisingly, the NetBeans IDE for PHP is a great contender, having improved vastly since I last used it more than 3 years ago. What I liked most is its support for Symfony2 out-of-the-box.
So the forth upgrade I am doing to my development environment is to move all my PHP projects into NetBeans, to take advantage of its integration capabilities with various plugins and workflow. I’ll still do quick/simple scripts in Komodo Edit (not every PHP script needs to be part of a formal project).
The third in a series of upgrades to my development environment is Apache HTTP Server (HTTPD for short). I mostly use it as a proxy server, security front door, and PHP/HTTP web server. The upgrade involves a move from version 2.2 to upgrade to 2.4:
- Download the installer from http://www.apachehaus.com/cgi-bin/download.plx. Choose Apache 2.4.x VC11 thread-safe and with OpenSSL. I avoid the x64 builds because a lot of modules I use are not compatible (and the builds are themselves experimental).
- Extract the .zip to a location where the web server will be run from. If you need to install it as a Windows service: D:\Web.Servers\Apache24\bin>httpd.exe -k install -n “Apache2.4″
- Update httpd.conf, specifically the port on which the server will listen. Start it up and ensure it runs in default configuration.
- Copy (or otherwise merge) config setting from the old installation to the new. This includes httpd.conf, websites, security certificates, and extensions/modules not already in the new installation, and other important files. As always, ensure your components are compatible in the new server. Update references in httpd.conf accordingly.
If you run PHP from Apache, ensure that the VisualC++ builds match (in my case, the PHP installed on my system is VC11, so I need to ensure Apache is also VC11). You do this to ensure compatibility of the php5apache2_4.dll. You can download updated Apache/PHP extensions or modules from http://www.apachelounge.com/download/additional/.
If you get errors such as the below, review the Windows event logs and Apache’s own error log to determine what the root cause is:
The Apache2.4 service could not be started.
A service specific error occurred: 1.
More help is available by typing NET HELPMSG 3547.
The second upgrade of my development environment is PHP, from version 5.4 to the latest 5.5.4. Installing PHP is as simple as unzipping an archive and updating your environment variables:
- Download latest stable from http://php.net/downloads.php. You should consider the Windows binaries and source, VC11 x86 Thread Safe (x64 versions are experimental).
- Unzip the download to wherever PHP will be installed.
- Update environment variables to include the root directory of PHP installation.
The actual upgrade involves copying the php.ini from the old installation, finding/replacing directory references for old installation with the new ones. You may also want to copy any other /ext and /extras you had in the old installation to the new installation in respective relative locations. Be sure that those extensions and plug-ins are compatible with the new installation.
> php -v
PHP 5.5.4 (cli) (built: Sep 18 2013 13:04:23)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
It feels like my whole development environment is outdated, so I am on a mission to upgrade everything, except perhaps the operating system. MySQL is the first component I upgraded, from 5.0 to the latest 5.6 (latest). The process is quite straightforward:
- Download the Windows installer from http://dev.mysql.com/downloads/mysql/. Oracle has done a good job with this installer; it does everything for you, including downloading and installing the features you need.
- Backup all databases in your current instance of MySQL:
mysqldump -u root -p<pwd> --all-databases > all-mysql-databases.sql
- Run the MySQL Installer, which will allow you to install new features, upgrade, or remove features. I upgraded the two main features I use: WorkBench CE from 5.2 to 6.0.6, MySQL Server from 5.0 to 5.6, installed samples and documentation.
- Add the new server installed /bin to system environment variable PATH, so tools can be accessible on commandline.
- Restore the database backup:
mysql -u root -p<pwd>< all-mysql-databases.sql
- Validate the upgrade.
mysql_upgrade -u root -p<pwd>
- Restart the MySQL service.
Often during development, I want to expose a web application for review to a limited set of people. The easiest way to do this is to impose a password when these users connect to the application. Most often, I configure a virtual host for the application in Apache-2.4 and set it up with basic HTTP authentication using passwords.
First, create the password file using the htpasswd.exe utility, and save it under /conf as users.pwd (or whatever you want). Then for the application’s virtual host, setup password protection:
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_file_module modules/mod_authn_file.so
# Password-protected resources
# Secure access
AuthName "Protected Sites"
Deny from all
ProxyPass / http://localhost:8091/
ProxyPassReverse / http://localhost:8091/
Restart Apache for changes to take effect. Access to :81 applications will pop-up a password dialog for the client.