For security reasons, it is important to take users out of sensitive screens after a defined period of user inactivity and return to a login prompt.

It also ensures your users will be running a current version of you HTML/JS files in case you have recently updated them. Otherwise they may run with old versions for days.

The EWB onidle timer calls your event after a defined period without any mouse clicks or keypresses. Mere mouse movements do not count.

The following code simply reloads the current Web page i.e. your whole EWB application if the idle state is detected.

The variable window.location.protocol should be HTTPS for security reasons. If it not, reload the page with HTTPS.

Many browsers will suggest input from previous Web page inputs. For example, Address, Name, Email, Credit Card information, etc. and this is called autocompletion.

When it is your own private data being entered on screens you will find this is convenient, especially on cell phones where keystroke entry is difficult. But if you are entering other data, this is actually frustrating and may lead to incorrectly substituting your personal data.

EWB TEdits behahvior for autocompetion is controlled with the autocomplete parameter which defaults to letting the browser decide.

If you know the field is not the user’s personal data, you should turn off autocompletion with

or set the property to acOff in the TEdit’s property editor.

This is not actually an EWB client feature, instead all the code is on the server.

You set an appropriate cookie on the server and then check that it is re-submitted by the client when they communicate with you.

Read up on how this helps reduce (but does not eliminate) XSS attacks on your web site.

TEdits and TMultiLineEdits have a maxlength value to prevent users from submitting long strings.

Consider these limits advisory, useful for users but not a guarantee.

Your server code should impose the hard limits, so excessively long strings cannot overflow buffers.

Univerally Unique IDs (UUIDs or GUIDs to Window users) are essentially unguessibly large numbers.

They are everywhere, including on YouTube video URLs.

They solve a number of problems in big computing, such as distributed systems like YouTube or Active Directory where there is no one single machine hosting or even creating the names for all users or files.

But they are useful on small systems too. One of their many uses is to eliminate attacks where users try to sequence their way through files on your system.

Suppose you have images of clients on your system - a reasonable enough possibility. If you name them customer0001.png through customer0031.png, then I can guess customer0032.png will likely give me an image of your next customer even though I shouldn’t know that, it also tells me you have only 31 customers if customer32.jpg returns file not found.

Using, say, customer-57483-4995-6655-4444.png for the filename means I can spend the rest of my days trying to query your system but I likely won’t be able to find that customer.

These numbers are random, but don’t use the Random() function to create them. Random on most systems uses a predictable algorithm. Most server systems have a true random number generator which uses complicated math and real-time system events to produce wholly unpredictable results. Look into the manual for your server technology for details.

Passing them through to EWB client is no problem. UUIDs can be part of normal strings, so just append them to filenames you pass from the server.

It’s often smartest to have the server assign the UUID, rather than the client, as client-assigned data is vulernable to attacks. So the client uplaods a file, and the server appends a UUID or replaces it with a UUID.

Your system will likely have one multiple privilege levels which will cause different screens to be enabled or available.

Your real security should be written into the server, the browser application should avoid showing screens that accept or display privileged information, but it is your server that should enforce the rules to ensure errant requests cannot set or request privileged information.

This is an advanced topic, but if you are worried about replay attacks or unauthorized requests from external programs, it is useful to have a complicated strategy which prevents such attacks.

The essential strategy is that the client and server each send each other a nonce (a random string), so those numbers are recorded by other, and they use shared alorithm that hashes the nonces along with a sequence number for each transaction following authentication.

The sequence number is always increasing. So if you use 32 bit counters, you are limited only to about 4 billion transactions before you run out of sequences in a single session.

So in each transaction, you send the sequence number and a hash function result:

The URL includes all other parameters. So some attacker in the middle cannot replace a parameter.

The other shared secrets could include a compiled-in application secret or the hash of the password if your system has internal passwords. (Most enterprise systems do not have internal passwords, they rely on Single Signon Passwords, but may have other secrets.)

An outside attacker would never see the nonces so they cannot accurately predict it, and thus cannot impersonate you by hijacking your session or

While the sequence increases, you could base it on the system (millisecond) clock rather than just the transcation number. That usually works a little bit better.

EWB works well with this sort of security because you don’t have to rememeber to add all the security for every transaction, instead you can create a enhanced class for the TServerRequest class and use that replacement class instead.

On the server, simply check that sequence has increased and the hash value matches the same calculated value from the shared nonces.

Erick