TPagePrinted = procedure(Sender: TObject; Canvas : TCanvas ;
NumPage, W, H: Integer ;
var StopPrinting : Boolean) of Object;
The TPagePrinted type is the type for the OnPrintHeader and OnPrintFooter events. These events occur as each page is printed allowing the user to add a header and/or footer to the page.
Canvas is the drawing canvas on which to draw the header or footer having its origin at the upper left corner of the header or footer area with a width, W, and height, H. The actual size of the header/footer areas is determined by the PrintMarginTop and PrintMarginBottom property settings.
NumPage is the current page number. StopPrinting may be set to True to stop printing.
Example:
This code prints the document title and filename in the header area.
procedure TForm1.PrintHeader(Sender: TObject; const Canvas: TCanvas;
NumPage, W, H: Integer; var StopPrinting: Boolean);
var
AFont: TFont;
begin
AFont := TFont.Create;
AFont.Name := 'Arial';
AFont.Size := 8;
with Canvas do
begin
Font.Assign(AFont);
SetTextAlign(Handle, TA_Top or TA_Left);
TextOut(50, 40, Viewer.DocumentTitle);
SetTextAlign(Handle, TA_Top or TA_Right);
TextOut(W-50, 40, Viewer.CurrentFile);
end;
AFont.Free;
end;
See also:


Preparation time
less than 30 mins
Cooking time
10 to 30 mins
Serves
Serves 8
Dietary
It is really important that the pears are firm for this recipe, or they will fall apart when you poach them. Poaching the pears can be done the night before.This also allows the syrup to cool and thicken.
Preheat the grill to hot.
Halve and core the pears, then cut each pear into 12 small wedges. Place in a heavy-based saucepan with the honey, port and wine. Cook for 10-15 minutes or until the pears are tender to the point of a knife but not soft.
Drain the liquid into a small pan and allow the pear wedges to drain thoroughly.
Reduce the liquid by two thirds, when it should be a syrupy consistency, this will take 8-10 minutes. Place in a small glass and allow to cool.
To make the bruschettas, brush each slice of bread with the olive oil, and then grill until the bruschettas are golden on both sides. This only takes a minute or two so keep a close eye!
Just before your guests arrive, generously spread each bruschetta with gorgonzola, top with a poached pear slice. Finally, using a teaspoon drizzle with the port syrup.


Guestbook
Waiting for database connection...
Career Level
1
2
3
4
5
6
7
8
9
10
11
12
13
Submit
/env
/info


XMLTask is an external task for the popular build tool Ant that permits complex manipulations of XML in a simple and consistent fashion, without having to deal with XML style sheets (XSL). XMLTask can be used for many common tasks that developers face, including manipulating J2EE and Spring descriptors, creating XHTML websites, and driving workflows via XML configuration files.
Developers often face having to automate the changing of XML documents during a build or deployment. The traditional means of doing this using Ant are by using the standard Ant tasks replace
or style/xslt
and defining an XML style sheet.
The replace
task works well for simple search/replace operations (for example, changing property files) but lacks the ability to perform powerful searches and complex replacement operations. Additionally, it is not XML-aware and can result in a non-"well-formed" XML document or a document with an inconsistent character set (this is particularly important when manipulating internationalized content such as XHTML).
Unlike replace
, the style/xslt
task performs XML-aware changes but at the price of greater complexity. The developer has to develop an additional XML style sheet as part of their build/deployment. Often this is not a trivial task.
XMLTask was developed to provide a mechanism for changing XML files in a simple and consistent fashion, providing tools to help with commonly encountered requirements in Ant builds. XMLTask allows developers to identify sections of XML, then insert, remove, and cut/copy/paste content. Content can be read from files, and moved between XML documents.
For the purposes of this article, we'll take a common example of XMLTask usage and modify a servlet descriptor for a deployment of a servlet-based application.
If you want to follow the article with a copy of XMLTask, you should download it before continuing here. XMLTask will work with any version of Ant 1.5 and above. The examples used below are available for download. See the Resources section for the appropriate links.
XMLTask requires referencing in your Ant build.xml file like any other external task. Simply use:
<taskdef name="xmltask" classname="com.oopsconsultancy.xmltask.ant.XmlTask"/>
XMLTask requires a source file to read, and a destination file to write to. (These can be the same file, but this practice is discouraged unless you have an appropriate backup!) You can specify source and destination files using the appropriate attributes:
<!-- modify the servlet --> <target name="servlet"> <xmltask source="src/web.xml" dest="target/web.xml"> <!-- nothing to do here yet --> </xmltask> </target>
Given the above, XMLTask will simply read in the file src/web.xml, perform no modifications, and write the resultant XML out to target/web.xml. The input file src/web.xml will not be changed.
Now you need to tell XMLTask what to do with the contents of src/web.xml. You give XMLTask a set of instructions for changing the XML content, and identify the elements that XMLTask will operate on by using the standard XPath syntax--a path-like notation for finding XML content. A complete explanation of XPath is outside the scope of this document, but the examples below use straightforward XPath expressions and should be readily understandable. Some tutorials are referenced in the Resources section for those who wish to investigate XPath in greater depth.
Each XMLTask instruction works by specifying an XPath to an XML element, and what to do for that element. If an XPath resolves to more than one XML element, then XMLTask will apply the instruction to each XML element specified. If an XPath resolves to no XML elements then that instruction will not be applied at all. You can instruct XMLTask to fail in these scenarios by setting the 'failWithoutMatch'
attribute to 'true'
.
Let's look at some simple usages of XMLTask.
You can use XMLTask to insert text and XML content specified either in the Ant build script on in external files. Let's take a standard servlet descriptor (web.xml
) without an application name:
<?xml version="1.0" encoding="UTF-8"?> <web-app id="ApplicationName" version="2.4"> <display-name></display-name> .... </web-app>
You can use XMLTask to insert a display name. You can imagine scenarios where you would want to do this dynamically--generating a development and production version of your servlet application, inserting the build time/date, etc.
<xmltask source="src/web.xml" dest="target/web.xml"> <insert path="/web-app/display-name" xml="Development Application"/> </xmltask>
which results in:
<?xml version="1.0" encoding="UTF-8"?> <web-app id="ApplicationName" version="2.4"> <display-name>Development Application</display-name> .... </web-app>
You can see that the <insert>
instruction identifies where the insertion must occur (by specifying a path to the XML to be changed: /web-app/display-name
) and what should be inserted. <insert>
can insert simple text, XML specified in the Ant script, or the content of a file. To illustrate both the more complex XML insertion and specifying the position of insertion, let's insert a new chunk of XML into web.xml
to configure a servlet. The XML is contained within a CDATA
section within the <insert>
instruction.
<xmltask source="src/web.xml" dest="target/web.xml"> <insert path="/web-app/servlet[1]/servlet-class" position="after"> <![CDATA[ <init-param> <param-name>parameter 1</param-name> <param-value>value for parameter 1</param-value> </init-param> ]]> </insert> </xmltask>
which will insert the new <init-param>
section specified after the <servlet-class>
section of the first servlet definition. The resultant descriptor will look like:
<?xml version="1.0" encoding="UTF-8"?> <web-app id="XmlTaskDemo" version="2.4"> <display-name/> <servlet> <servlet-name>UnitTests</servlet-name> <servlet-class>com.oopsconsultancy.servlet.tests.UnitTests</servlet-class> <init-param> <param-name>parameter 1</param-name> <param-value>value for parameter 1</param-value> </init-param> ....
You can insert the contents of a file (called, in this example, insertion.xml).
<xmltask source="src/web.xml" dest="target/web.xml"> <insert path="/web-app/servlet[1]/servlet-class" position="after" file="insertion.xml"/> </xmltask>
The XML that is inserted can be an XML document fragment and consequently doesn't have to have a root node. So a valid file for insertion can look like:
<!-- common servlet initialisations --> <init-param> <param-name>parameter 1</param-name> <param-value>value for parameter 1</param-value> </init-param> <init-param> <param-name>parameter 2</param-name> <param-value>value for parameter 2</param-value> </init-param>
You can remove content just as easily.
<xmltask source="src/web.xml" dest="target/web.xml"> <remove path="/web-app/servlet-mapping[servlet-name/text() = 'UnitTests']"/> </xmltask>
This tells XMLTask to remove the <servlet-mapping>
section that has a <servlet-name>
section of 'UnitTests'
. Note that if you'd specified the instruction as simply:
<xmltask source="src/web.xml" dest="target/web.xml"> <remove path="/web-app/servlet-mapping"/> </xmltask>
then we'd remove every <servlet-mapping>
section.
<remove>
will tell XMLTask to remove the XML element defined and everything below it. A common requirement is to simply remove the text content within an XML element. You can do that just as easily.
<xmltask source="src/web.xml" dest="target/web.xml"> <remove path="/web-app/display-name/text()"/> </xmltask>
which will remove the configured display name, but leave behind the XML elements defining it.
You can replace XML easily using the <replace>
instruction.
<xmltask source="src/web.xml" dest="target/web.xml"> <replace path="/web-app/servlet[1]/servlet-class/text()" withText="com.oopsconsultancy.examples.NewServlet"> </xmltask>
will remove the text under the <servlet-class>
element in the first servlet and replace it with the new servlet class specification, com.oopsconsultancy.examples.NewServlet
. Note that you can use <insert>
here, but it would instead insert text adjacent to the existing text under the <servlet-class>
element.
To modify an attribute, you can use an XPath expression with an attribute identifier.
<xmltask source="src/web.xml" dest="target/web.xml"> <replace path="/web-app/@id" withText="New Application"> </xmltask>
This performs a replacement on the 'id'
attribute of the <web-app>
element (the '@'
symbol is used by XPath to indicate an attribute).
A trivial way to change XML configurations is to have one master configuration containing all the required elements, with those not required commented out. It's a simple task to then uncomment those sections required, while having the ease of maintaining only one file. XMLTask allows you to create multiple XML documents from a master very easily, by allowing you to determine which elements are commented/uncommented during a build.
Given a web.xml that contains two different versions of a servlet configuration, both disabled by default:
<?xml version="1.0" encoding="UTF-8"?> <web-app id="XmlTaskDemo" version="2.4"> <display-name>Application</display-name> <!-- <servlet> <servlet-name>Pricing Model 1</servlet-name> <servlet-class>com.oopsconsultancy.pricing.model1</servlet-class> ... </servlet> --> <!-- <servlet> <servlet-name>Pricing Model 2</servlet-name> <servlet-class>com.oopsconsultancy.pricing.model1</servlet-class> ... </servlet> -->
XMLTask can enable any of these by uncommenting the appropriate element.
<xmltask source="src/web.xml" dest="target/web.xml"> <uncomment path="/web-app/comment()[2]"/> </xmltask>
will uncomment the 2nd commented section. Note that to specify a comment, you have to use the XPath comment()
function.
XMLTask can chain these simple instructions together to provide a means to perform complex modifications of a file. For instance, in the example below, you can read the source web.xml
, insert content, change attributes and remove content, and write out to a new target web.xml
.
<xmltask source="src/web.xml" dest="target/web.xml"> <replace path="/web-app/@id" withText="New XMLTask Demo"/> <insert path="/web-app/servlet[1]/servlet-class" position="after"> <![CDATA[ <init-param> <param-name>parameter 1</param-name> <param-value>${dev.property}</param-value> </init-param> ]]> </insert> <remove path="/web-app/servlet[1]/load-on-startup"/> </xmltask>
The above changes the application id
to 'New XMLTask Demo'
, inserts a servlet initialization parameter, and removes the <load-on-startup>
element and contents. Note that if the Ant property dev.property
(referenced in the insertion) has been assigned a value, it will be expanded during the <insert>
instruction. Each XMLTask instruction operates on the XML resulting from the last instruction--not the original document. So, for example, removing the first servlet definition will then mean that the second servlet definition becomes the first, and so on.
To diagnose sets of instructions and understand what effect each instruction has, you can switch on reporting.
<xmltask source="src/web.xml" dest="target/web.xml" report="true">
This prints the XML document out after each XMLTask instruction.
XMLTask can cut, copy, and paste among XML documents. The XML cut or copied is stored in a buffer, which can be used to paste into the same document or a different one loaded by a new XMLTask instance.
A common usage scenario is to use a document as a template, copy one section of it and then replicate through the document by pasting the section back in, and changing each pasted section.
<xmltask source="src/web.xml" dest="target/web.xml"> <!-- copy the first servlet --> <copy path="/web-app/servlet[1]" buffer="servlet-buffer"/> <!-- paste a copy back in after the first servlet --> <paste path="/web-app/servlet[1]" position="after" buffer="servlet-buffer"/> <!-- and change the name --> <replace path="/web-app/servlet[2]/servlet-name/text()" withText="UnitTests-2"/> </xmltask>
The above copies the first servlet definition within the src/web.xml
into a buffer called servlet-buffer
. It then pastes it back into the web.xml
from 'servlet-buffer'
after the first servlet definition and changes the name.
Any number of buffers can be defined, each with an arbitrary name, and they will persist for the lifetime of the Ant build. So a buffer can be written to in one XMLTask instance, and written out during another.
<xmltask source="src/web.xml"> <copy path="/web-app/servlet[1]" buffer="servlet definition"/> </xmltask> <xmltask source="src/web-2.xml" dest="target/web-2.xml"> <paste path="/web-app/servlet[1]" position="after" buffer="servlet definition"/> </xmltask>
The above uses two XMLTasks to copy and paste between different files. The first XMLTask copies some XML from src/web.xml
. Note that because you're simply copying into a buffer (called 'servlet definition'
) then you don't need to tell XMLTask to write out to a destination file.
The second XMLTask reads src/web-2.xml,
and pastes the contents of the buffer into it (after the first servlet definition). This then gets written out as target/web-2.xml
.
Buffers can be appended to from multiple <cut>
or <copy>
instructions. For example, you may want to select a number of servlet definitions and write them into a new web.xml
. The first stage (the copying) would look like this:
<!-- we want to copy the 1st, 3rd and 4th servlet definitions --> <xmltask source="src/web.xml"> <copy path="/web-app/servlet[1]" buffer="sbuf"/> <copy path="/web-app/servlet[3]" buffer="sbuf" append="true"/> <copy path="/web-app/servlet[4]" buffer="sbuf" append="true"/> </xmltask>
To see the contents of a buffer (for diagnostic purposes) you can print it out to standard out.
<xmltask source="src/web.xml"> <copy path="/web-app/servlet[1]" buffer="sbuf"/> <print buffer="servlet definition"/> </xmltask>
XMLTask can read its initial input from a buffer, and write the results of a set of instructions to a buffer. You can simply specify a sourcebuffer
instead of a source
file, and/or a destbuffer
instead of a dest
file. The below creates an XML document from scratch, and writes it to a buffer (for later copying/pasting).
<xmltask destbuffer="dest buffer"> <insert path="/"> <![CDATA[ <web-app id="new webapp!"/> ]]> </insert> </xmltask>
XMLTask doesn't require a source document, since you're creating a new document. The <insert>
creates a root element called <web-app>
, and that gets written to the buffer 'dest buffer'
when XMLTask completes. This buffer is now available for further XMLTask targets to use.
XMLTask can write to Ant properties in the same fashion (by specifying property
instead of buffer
in the cut
, copy
, and paste
instructions). However, there are a couple of caveats to be aware of. The first is that Ant properties are immutable. Consequently they can't be re-written or appended to. The second issue is that properties store text only. If you have specific character encoding requirements with your XML, then converting document fragments to text may cause difficulties later on. It's advisable to use XMLTask buffers in preference to properties wherever possible for these reasons.
When manipulating XML documents that have or require document type definitions (DTDs), you need to tell XMLTask how to handle these. DTD configuration falls into two categories:
For example, a Servlet spec 2.3 web.xml document will begin:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app id="XMLTask Demo" version="2.3"> ....
XMLTask will attempt to load this DTD from http://java.sun.com. If you're behind a firewall then this will fail, and your build will exit with a (usually unexpected) java.net.ConnectException.
Fortunately Ant provides a mechanism to disable this remote lookup, and XMLTask can take advantage of it.
You can use the Ant <xmlcatalog>
to specify a local location for the above DTD:
<xmlcatalog id="dtd"> <dtd publicId="-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" location="./servlet-2.3.dtd"/> </xmlcatalog>
specifies a catalog of XML DTDs called dtd
. For the required DTD with the public ID from Sun Microsystems, you should specify a local copy in the file ./servlet-2.3.dtd. (simply capture a copy via the given URL and your browser).
You now need to tell XMLTask about this.
<xmltask source="src/web.xml" dest="target/web.xml"> <xmlcatalog refid="dtd"/> </xmltask>
XMLTask will use the local copy of the DTD in ./servlet-2.3.dtd
in preference to the remote copy.
Because XMLTask is performing transformations on the document you may need to tell it what DTD schema the resultant document should be output with (remember that XMLTask will not perform a validation--the optional <xmlvalidate>
task is appropriate for this). If XMLTask is outputting a modified document that conforms to the DTD referenced in the source document, then you can tell XMLTask to re-use this:
<!-- we're amending a 2.3 web.xml document --> <xmltask source="src/web.xml" dest="target/web.xml" preserveType="true">
If you want to output a document with a new DTD, then you have to specify the public and system IDs used by that DTD.
<!-- we're creating a 2.3 web.xml document from scratch --> <xmltask source="src/web.xml" dest="target/web.xml" public="-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" system="http://java.sun.com/dtd/web-app_2_3.dtd">
XML documents containing multiple XML namespaces are increasingly common. XMLTask can handle these, but you need to be a little more careful when creating your XPath specifications. For instance, a servlet 2.4 web.xml file will begin:
<?xml version="1.0" encoding="UTF-8"?> <web-app id="XMLTask Demo" xmlns="http://java.sun.com/xml/ns/j2ee" version="2.4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http:/java.sun.com/dtd/web-app_2_4.xsd"> <display-name>Application Display Name</display-name> <servlet> ....
and the default namespace is set to "http://java.sun.com/xml/ns/j2ee"
. Although the remainder of the web.xml looks perfectly normal, you need to modify your XPath specifications to take account of multiple namespaces, and specify XML elements appropriately. A full discussion of XPaths and namespaces is beyond the scope of this document--however, the solution is straightforward and simply requires us to specify the local name of the XML elements required.
<insert path="/web-app/display-name" xml="New Application Name"/>
becomes:
<insert path="/:web-app/:display-name" xml="New Application Name"/>
Scoping each XML element name with a preceding ':'
is sufficient to tell the XPath mechanism that you're interested in the local name of the element.
XMLTask has the facility to read XML files during an Ant build and execute Ant targets according to the contents of these files. This facility makes it straightforward for you to drive an Ant build by using a configuration file, an XML file output from an earlier process or similar.
For example, you may have a file, build-configuration.xml, representing a set of builds required.
<builds> <build>development</build> <build>systemtest</build> <build>production</build> </builds>
This specifies that you need a development version of your software, a system test version, and a production version. XMLTask can read this configuration and call Ant targets to build your software according to the above configuration.
<!-- drives the build --> <target name="main"> <xmltask source="build-configuration.xml"> <call path="/builds/build" target="compile-and-release"> <param name="build.version" path="text()"/> </call> </xmltask> </target> <!-- performs a build --> <target name="compile-and-release"> <echo>Building ${build.version}</echo> .... </target>
The XMLTask reads the input file build-configuration.xml and calls the Ant target 'compile-and-release'
for each <build>
element it encounters. For each 'compile-and-release'
target called, the property 'build.version'
is set to the text contents of the <build>
element. In this example this would be development
, systemtest
, and production
. By changing the contents of build-configuration.xml
, you can change the build output. The above configuration would result in three separate builds.
XMLTask allows the straightforward modification of XML documents by using the power of XPath to identify XML elements to change, but without the pain of learning XSL. You've seen during this article how to perform insertions, replacements, and deletions to permit simple maintenance of XML files, including (but not limited to) J2EE descriptors, Spring configurations, and XHTML documents. XMLTask can be used to parse XML configurations and drive Ant builds. It's worthwhile visiting the XMLTask home page to see more features not addressed here, and for further examples.


AMany body washes can strip the skin of its natural oils and leave it dehydrated, flaky, red, and irritated. Over time, argan oil helps balance the under-production of sebum, which keeps the skin moist and healthy.
Argan Oil Dry Skin Remedy:
Acne can be frustrating and embarrassing, even more so at times if you are an adult. However, many individuals have seen acne relief in the application of Argan oil. You may wonder how an oil could possibly reduce breakouts. Isn’t oil build-up what causes them?
It is important to note that most acne medications use benzoyl peroxide and salicylic acid, which can sometimes hurt more than help. Improper use of these ingredients can lead to dry, irritated skin, which can induce the over-production of oil and result in even more blemishes.
DSwitching to a natural healer like argan oil can balance skin’s moisture and even skin tone. Argan oil is also high in anti–inflammatory components such as anti-oxidants and vitamin E, thereby capable of soothing inflammation and blemishes naturally.
To enjoy a significant reduction in redness, flakiness, and blemishes, follow our Argan Oil Acne Treatment:
As someone with oily skin, the last thing you probably want to hear is a suggestion to apply even more oil to it. However, argan oil is known for balancing the production of sebum naturally released by the dermis. Sebum is produced to lubricate and protect our skin from the environment; sebum also tends to be overproduced when skin is lacking in moisture. Therefore, the sufficient application of a natural moisturizer is essential to decrease an oily appearance over time.
To use Argan Oil to Reverse Oily Skin:
CMany women opt for night creams and collagen treatments to reduce wrinkles. Some women don’t suffer from wrinkles but feel their skin lacks its once-beautiful radiance. It is important to understand what active ingredients can restore the youthful appearance of skin.
Triterpenoids in argan oil provide anti-inflammatory protection from sun, smoke, and other toxins that damage and dull skin tone. Argan oil also contains sterolins, which increase skin’s metabolism and promote moisture retention; lack of moisture is a prevailing cause of decreased collagen production and wrinkles. Finally, argan oil is rich in Vitamin E, which is widely recognized for its effective anti-aging properties.
Our Anti-Aging Argan Oil Treatment can return your youthful glow:
Having a baby is a beautiful thing, but sometimes, the changes it makes to your body are not. Fluctuations in weight can also lead to unwanted blemishes. Stretch marks and cellulite can be frustrating and seemingly impossible to get rid of. Argan oil is a wonderful natural remedy for these issues, and with some patience, you can enjoy the firm, youthful skin you once had.
Argan oil is rich in tocopherols and fatty acids that improve cell regeneration and protect our cells from free radicals’ damage. This means that argan oil not only reduces the appearance of stretch marks, but it also tightens skin and battles cellulite.
Argan Oil Regimen for Firmer Skin


Cordova Security Guide
This is a summary of the Cordova Security Guide.
Whitelist
Domain whitelisting is a security model that controls access to external domains over which your application has no control. Cordova provides a configurable security policy to define which external sites may be accessed. By default, new apps are configured to allow access to any site. Before moving your application to production, you should formulate a whitelist and allow access to specific network domains and subdomains.
Be aware that some websites may automatically redirect from their home page to a different url, such as using https protocol or to a country-specific domain. For example http://www.google.com
will redirect to use SSL/TLS at https://www.google.com
, and then may further redirect to a geography such as https://www.google.co.uk
. Such scenarios may require modified or additional whitelist entries beyond your initial requirement
Note that the whitelist applies only to the main Cordova webview, and does not apply to an InAppBrowser webview or opening links in the system web browser.
Iframes and Calback ID Mechanism
If content is served in an iframe from a whitelisted domain, that domain will have access to the native Cordova bridge. This means that if you whitelist a third-party advertising network and serve those ads through an iframe, it is possible that a malicious ad will be able to break out of the iframe and perform malicious actions. Because of this, you should generally not use iframes unless you control the server that hosts the iframe content.
Certificate Pinning
Cordova does not support true certificate pinning. The main barrier to this is a lack of native APIs in Android for intercepting SSL connections to perform the check of the server’s certificate. Since Apache Cordova is meant to offer consistent APIs across multiple platforms, not having a capability in a major platform breaks that consistency.
There are ways to approximate certificate pinning, such as checking the server’s public key (fingerprint) is the expected value when your application starts or at other various times during your application’s lifetime. There are third-party plugins available for Cordova that can do that. However, this is not the same as true certificate pinning which automatically verifies the expected value on every connection to the server.
Self-signed Certificates
Using self-signed certificates on your server is not recommended. If you desire SSL, then it is highly recommended that your server have a certificate that has been properly signed by a well-known CA (certificate authority). The inability to do true certificate pinning makes this important. The reason is that accepting self-signed certificates bypasses the certificate chain validation, which allows any server certificate to be considered valid by the device.
Encrypted storage
For encrypted storage, you could consider using one of a number of secure storage plugins for Cordova. The cordova-plugin-secure-key-store plugin uses the Android Keystore and the iOS Keychain for stores sensitive data.
General Tips
Use InAppBrowser for outside links
Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser’s security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
If you want all page loads in your app to go through the InAppBrowser, you can simply hook window.open
during initialization. For example:
document.addEventListener("deviceready", onDeviceReady, false);
function onDeviceReady() {
window.open = cordova.InAppBrowser.open;
}
Validate all User Input
Always validate any and all input that your application accepts. This includes:
-
usernames
-
passwords
-
dates
-
uploaded media etc.
Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like chrome://inspect), this validation should also be performed on your server, especially before handing the data off to any backend service.
Other sources where data should be validated include:
-
User Documents
-
Contacts
-
Push Notifications
Do not cache sensitive data
If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
Do not assume that your source code is secure
Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application to recover sensitive app data or hardcoded keys etc.


Add a Record
Name
Email
Age
Invalid Age
Country
Phone Number
Global errors:
All errors in place:
This is outside the form:
Errors on a single field:
All errors: