WebHub tracks surfers with Session IDs instead. Session IDs expire, and a developer can set an inactivity timeout, so that after N minutes, even if another person does sit down at the machine and follow a page, that page will have expired and re-login will be required.
Surfer data is kept on the server machine -- no database vulnerability
Data doesn't travel unnecessarily back and forth via cookies or hidden fields on forms. It is simply saved and restored based on the surfer's Session ID.
There is never any SQL code visible through View|Source of the web pages. The SQL code is kept on the server machine and never sent to the surfer. That means a surfer cannot save your web page, change a few keywords, and break into your database.
For highest performance and highest security, HREF recommends putting the database on a separate machine and connecting to it using a second network card which is not open to the Internet, just to the web server machine.
True comments -- your code is not visible
WebHub has its own comment syntax, enabling you to put in-house comments into your HTML. WebHub comments are stripped out before the HTML goes to the surfer, so your ideas and notes are completely private.
Even if you don't use any WebHub comments, a surfer will not be able to figure out what you did with WebHub macros by viewing your web pages. Surfers can see only the result of all the processing, never the code that caused it.
A single WebHub setting called "frontdoor" helps you make sure that surfers always come in through a "front door" page, regardless of what they may have bookmarked.
WebHub VCL programmers can adjust internal component settings to further increase security by monitoring each session for changed in IP number and/or browser type. While a change in IP number does not necessarily indicate an attempted break-in (because AOL and other networks pool IPs), if that change occurs in conjunction with a suspicious prior-link, then the application server software can reject the surfer.
The same thing goes for changes in browser type. While it is legitimate to change browsers during testing, it is quite rare for a real surfer to do this, and a programmer can decide to use this event as a security-risk flag.
WebHub Power HTML and WebHub VCL include a component which lets you set up lists of allowed users, passwords, and pass phrases (hints). Surfers are then required to login before using certain pages, or even parts of pages, within your site. You can set up a security system based on any number of levels of access.
WeHub v1.50+ includes a macro making it easy to check whether there has been too long of a delay since the surfer last used the application. Let's say the threshhold is 30 minutes. That means that if the browser is idle for 31 minutes and then someone (maybe the legitimate user, maybe not) tries to follow a link, the application would require a second login to confirm the identity of the user.
WebHub supports HTTPS
Many people ask whether WebHub "does HTTPS". HTTPS stands for HyperText Transfer Protocol - the Secure Version. It is the web server software that does the work of encrypting and decrypting web pages to meet the HTTPS standard. WebHub simply works with both HTTP and HTTPS, but it does not provide the functionality.