The system heavily uses tinyMCE for HTML editing. Apple is no longer releasing updates for IPad 1 which has bugs which prevent tinyMCE from working as a result we can no longer support iPad1.
We support the latest version of Google Chrome and FireFox (which automatically updates whenever it detects that a new version of the browser is available). We support the current and previous major releases of Safari on a rolling basis. Each time a new version is released, we begin supporting that version and stop supporting the third most recent version.
Internet Explorer 11 launched on October 17, 2013. The best Internet Explorer experience will be had on the latest version of the browser. Our support of Internet Explorer 8 is about to end as it is not compatible with newer web features. Due to browser limitations some features may be disabled on the older versions of IE.
stSoftware heavily relies on bootstrap, the upcoming release of bootstrap 4 will be removing support for IE8. We will remove support for IE8 at the same time.
All browsers must have cookies and JavaScript enabled to use stSoftware systems.
We support the latest versions of the following browsers and platforms.
| Chrome | Firefox | IE | Safari | |
|---|---|---|---|---|
| Android | Supported | Supported | N/A | N/A |
| iOS | Supported | N/A | Supported | |
| Mac OS X | Supported | Supported | Supported | |
| Windows | Supported | Supported | Supported | Not Supported |
Incidences of "Invalid HTTP request" have been seen when the websense proxy server is used. The proxy server must be configured to allow all SSL traffic to the server.
The system is a pure Java SE implementation. All extensions required to the standard JDK7+ install come bundled with the system installation. The system is intended as a large multi-user web application, having large internal data caches which require generous amounts of RAM on the server machine.
The server is compatible with standard Java servlet 3.0 or above container. Supported servlet containers include :
The server is operating system independent which means that the server will operate on any Windows, Macintosh, Linux or UNIX machine that supports our minimum requirements.
The stSoftware system is equally effective over a wide or local area network, or delivered via the internet, but it is worth noting that performance is directly affected by the standard of the infrastructure used therefore system speed will be improved by using a higher capacity network, internet connection, or PC.
Please note these are the MINIMUM system requirements, see the IDEAL system design.
stSoftware systems are built from the ground up on a unique multi-layered database structure which allows documents, articles, business rules and all other types of data to be selectively and securely shared across many systems and sites.
A layered database system is the aggregation of the layers below by selectively placing data and documents in different layers they can be securely shared across the different systems.
Detailed design of a layered database system Multi-Layered DB Application-document
The system administrator can configure the system password management and storage options to find the correct balance between convenience, performance and security. The password and login options can be configured at the global level and at a per user level.
| Type | Description |
| Best Practice 2017 |
A salted & PBKDF2 hash of the password with 23456 iterations. The resulting hash is stored in the database as an encrypted value. Key length 1024 Performance
Advantages:-
Risks:-
References:-
|
| Encrypted Salted PBKDF2 and SHA-512 Hashed 1234 times. |
A salted & PBKDF2 hash of the password with a large number (1234) of iterations. The resulting hash is stored in as encrypted value with a key length of 64 Performance
Advantages:-
Risks:-
References:- |
| Encrypted Salted SHA-512 Hash |
A salted and SHA-512 hash of the original password stored in as encrypted value. Advantages:-
Risks:-
|
| Salted Encrypted |
The password with a random salt is stored in an encrypted format in the database. The encryption key is stored in a separate database to the encrypted value. Risks
Advantages
|
Industry standard best practice for passwords for both the web server and Linux machines. Site designers do not have direct access to the underlying Linux server, the raw database or files. All changes are done within sandbox of the system.
All databases are backed up nightly.
All client documents are backed up nightly and consistency check of the raw file checksum is performed.
The backups are kept for a week on site.
The machines themselves are backed up as a whole to an off site secure backup location. A full or partial restore of the machine can be done from the off site recovery centre.
The standard system is Linux will all ports closed except HTTP, HTTPS and SSH.
SSH is configured to block IP addresses after a series of failed log in requests. All SSH requests that are from unknown locations or from foreign countries are blocked by default.
All raw files which are stored separately to the database itself are sent to both the main site and the disaster recovery site when the files are uploaded. Each version of a file is kept and never modified ( new version created ). When a file is uploaded a file checksum of the raw file is performed and stored in the database, the file is then encrypted and the key is stored in the database. The compressed/encrypted resulting file is sent to the redundant file servers for permanent storage.
The hosting provider has a 2 hour hardware replacement,
Online technical documentation
Our Sydney based help desk is staffed normal office hours of 9am-5pm Monday-Friday. Call us on 1300 78 73 78
For all non-urgent issues, please complete the contact us form and we'll be in touch during normal office hours of 9am-5pm Monday-Friday.
Use JobTrack's iCal button to easily view your time critical sales dates & job schedules on Google Calendar, Apple iCal or Microsoft Outlook.
The new iCal button makes it so easy to integrate your JobTrack data with iCalendar* applications like Google Calendar. This means you can view time critical database information conveniently on your preferred on-line calendar application on your mobile or other devices.
Imagine the benefits when your sales staff can see all their sales opportunity critical dates on their Google Calendar app or your Project Manager can quickly review job deadlines by day or week or month on their mobile device. You can simply click on your JobTrack iCalendar entry to instantly open the record in JobTrack to update or edit the item.
iCal integrated Modules: Quick Start, Jobs, Quotes and Sales Opportunity.
Repeat steps 1 and 2 on Quick Start, Sales Opportunities and Quotes modules to set up iCalendar feeds for each of those modules.
1. Go to the Jobs module and press the iCal button.
2. The system will generate a URL to add your Job dates to any iCalendar application like Google Calendar. 
3. You can talk to us about customising your iCalendar feed to sort & display a tailored view of your JobTrack information and links back to modules: Quick Start tasks & events, Sales Opportunities, Quotes or Jobs. 
To subscribe to your JobTrack iCalendar feeds using Google's Calendar application follow steps 1 and 2 for each Calendar URL you have generated using the iCal button.
To subscribe to your JobTrack iCalendar feeds using Apple's iCal program follow steps 1 and 2 for each Calendar URL you have generated using the iCal button.
*iCalendar is a popular file format used to distribute calendar information between different applications. For more information go to http://en.wikipedia.org/wiki/ICalendar
The standard install comes pre bundled with:-
The following are the main directories:-
To run a task from the command line you would call:-
java -jar launcher.jar build
In the above command "build" is the Ant task name defined in bin/launcher.xml
All web access is recorded in the standard Apache web access logs.
The server logs can be configured via log4j
All database changes are logged by user and time.
A cluster of servers (two or more ) can be setup and the DNS entry for your site can be defined with the IP addresses for each of the servers, this is known as Round-robin DNS
Now the DNS server returns both IP addresses for each www query, in random order. If both web servers are up, obviously no problem. If one is down. the questions are, will the browser try the second IP address. and how long does it wait to do so?
Ideally the static IP of one server would be from one network provider and the other server IP would be from another network provider. This means we are not reliant on one network provider.
The client browser will choose one of the identical servers. If it can't connect to one then it will try the other.
Using recent versions of IE (8 and above), Opera, Safari, Firefox and Chrome. The browser will try one web server and if it can not connect the browser will try the next server, the process is user-transparent, and occurs only if the first server tried times out, and only for the first page requested from our site in any browser session.
The DNS round robin works best if the server is actually off not just slow/timing out as the modern browser can move to the next very quickly.
Browsers older than IE8 are not supported by the ST web application, but may still be used to view the web sites. Old browsers such as IE7 will only use the first IP address.
During periods when one server was down, users of non-switching browsers ( IE7 ) would have a 50% chance of getting the bad server in an individual browser session. The usage of IE7 is now down to below 1% of web traffic for these browsers there is no advantage but a pretty big win for all modern browsers.
Note: Users with IE7 are prevented from logging into any ST servers due to the lack of HTML5 support but can be used browse the web sites.
When we do a lookup on google the DNS returns 4 IP addresses:-
host www.google.com
www.google.com has address 74.125.237.210
www.google.com has address 74.125.237.212
www.google.com has address 74.125.237.208
www.google.com has address 74.125.237.211
www.google.com has address 74.125.237.209
www.google.com has IPv6 address 2404:6800:4006:806::1010
Repeating the lookup returns a different set of IP addresses:-
host www.google.com
www.google.com has address 74.125.237.177
www.google.com has address 74.125.237.178
www.google.com has address 74.125.237.176
www.google.com has address 74.125.237.180
www.google.com has address 74.125.237.179
www.google.com has IPv6 address 2404:6800:4006:806::1011
After you have registered a new domain name with a domain name (DNS) provider such goDaddy, or you have an exisiting domain name, you need to change the associated IP address so that your domain name points to stSoftware's servers.
Or contact us to add "Assigning your domain name" service to your website or websystem package and we'll manage it for you.
Have your DNS pointed to either of the two groupings of IP addresses below;
101.0.96.194 & 101.0.96.198
or
101.0.96.195 & 101.0.96.197
Once your domain name has been assigned to our servers you need to contact us so we can associate your domain name with your new website or web system.
IMPORTANT: Please remember when assigning your domain name to our servers to keep your MX record (mail address) pointing to your existing mail servers.
NOTE: it takes some time for your DNS changes to propogate around the world, you can watch it propogate here http://www.whatsmydns.net/
TIP: If your DNS provider supports multiple IPs for one host name then set up simple redundancy with a DNS round robin.
All Linux servers are locked down to the highest security standards possible. All services are off by default and all ports shut. Only the required services started.
To lock down a server:-
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install openssh-server denyhosts vim oracle-java7-installer postgresql landscape-client htop lynx-cur
Ubuntu has a simple firewall configuration tool called ufw which is really just a simplified iptables interface.
sudo ufw allow ssh sudo ufw allow imap sudo ufw allow http sudo ufw allow https sudo ufw disable sudo ufw enable
Redirect the high permission ports 80 (http) and 443 (https) up to a port range that can accessed by the low permission user running the web service. Redirection of the ports can be done by the following iptable rules
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
-A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
Avoid running any custom code or the web server as a high permission user. A security floor in either the web server or your code will be run as the user that runs the web server.
sudo groupadd www-data
sudo useradd -g www-data -m -s /bin/bash webapps
Never allow direct ssh access to the ROOT account or any other functional account such as webapps. Each admistrator that should have access to these accounts must login under their own user accont and then sudo to the correct functional account.
To block all SSH access to ROOT add the option "PermitRootLogin no" to /etc/ssh/sshd_config
sudo vi /etc/ssh/sshd_config <--- PermitRootLogin no
This will help handle DOS attacks, and cope with a large number of slow clients.
Set the system wide maximum file handles:-
sudo vi /etc/sysctl.conf
fs.file-max=65535
Set the low permission user 'webapps' to allow the maximum possible files open.
sudo vi /etc/security/limits.conf
@www-data soft nofile 65535
@www-data hard nofile 65535
After rebooting check the max number of files have been increased.
sudo -u webapps -i "ulimit -a"
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 386171
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 386171
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
We recommend at least quarterly maintenance release are installed to your test environment, tested then promoted to your production system as part of the normal software maintenance cycle.
Regular and timely updates reduce the risks of running a live system that is out of sync with stSoftware's current version and enables your users to benefit from our R&D program, which is our investment and commitment to continually improve our systems for our customers (in recent years we have typically invested over $250,000.00 annually in our R&D program).
In our updates we release;
The main external components that the system relies on are Java and the underlying database itself. The operating system, Java and the database must also be maintained with regular upgrades.
See the Java support schedule, Java 6 was "end of life" as of Feb 2013. The stServer will run on the current supported version of Java, as of March 2014 Java 7 is the only supported version. Java 7 will be supported until at least March 2015
SQL injection is a code injection technique, used to attack data driven applications like stSoftware.
stSoftware systems support a number of web accessible protocols including:-
All protocols access the underlying data through the DAL ( data access layer). There is NO direct access to the underlying data store no matter which protocol is used. Each protocol accepts the request to read or write data and then perform the protocols validations and then passes the request on to the DAL to execute the request which in turn validates the request, checks the user's access and perform any validations before returning the result.
SQL & XSS attacks are automatically tested for each of the supported protocols. Listed below are the standard SQL injection strings attempted.
| SQL Injection String |
| "&%00<!--\'';你好 |
| \'; DROP TABLE users; -- |
| ''; |
| \' |
| \''; \'';:Contact-Delete |
| '\''; \''; |
| \u00F0\u009F\u00BF\u00B1\u00F0\u00AF\u00BF\u00B2\u00F0\u00BF\u00BF\u00B3\u00F1\u008F\u00BF\u00B4\u00F1\u009F\u00BF\u00B5\u00F1\u00AF\u00BF\u00B6\u00F4\u008F\u00BF\u00B7 |
| \u00EF\u00BB\u00BF\u00FF\u00FE\u00FF\u00FF\u00FE\u00FF\u2060 |
| \u001E\u0100 |
| \u001E\u00f0\u00f1\u00f2\u00f3\u00f4\u00f5\u00f6\u00f7\u00f8\u00f9\u00fa\u00fb\u00fc\u00fd\u00fe\u00ff |
| \uE000 |
| \uD7FF |
| \ufffe |
| € |
| €123 |
| &€123 |
| ';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//alert(String.fromCharCode(88,83,83))//;alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT> |
| ' or 1=1;-- |
| {? = CALL addJdbcExampleTrade (1, 'john', 32, '2004-10-22') } |
| {call ...} |
| {?= call ...} |
| {fn ...} |
| {oj ...} |
| {d ...} |
| {t ...} |
| {ts ...} |
| ©¡¢£¤¥¦§¨ª¬®°º»¼½¾¿ ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß àáâãäåæçèéêëìíîï ðñòóôõö÷øùúûüýþÿ |
| abc'$ |
| '''''""""$$$$\\\'\$$ |
| $$$$$ |
| $global.id$ |
| \$ |
| ==== |
| +++ |
| # |
| #23; |
| #abc; |
| #abc;#23;########;# |
| RT @ClimateGroup - RT @EurActiv: #23;Solar #23;recession signals end of \''Wild West\'' gold rush http://t.co/GHFL9g2p #23;EU #23;renewable #23;energy |
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ |
| Bob&Sons |
| Mr 5%3 |
| My & name |
| hacker '; games |
|  |
| you+me |
| -- ;DELETE FROM Login; |
| "" |
| /*comment */ |
| SELECT /*!32302 1/0, */ 1 FROM tablename |
| ID: 10; DROP TABLE members /* |
| SELECT /*!32302 1/0, *\/ 1 FROM tablename |
| admin' -- |
| admin' # |
| admin'/* |
| ' or 1=1 or ''=' |
| ' or 1=1-- |
| ' or 1=1# |
| ' or 1=1/* |
| ') or '1'='1-- |
| ') or ('1'='1-- |
| " or 1=1-- |
| or 1=1-- |
| ' or 1=1 or ' '= ' |
| >]]></Description> |
| <Description xmlns=""><![CDATA[ |
| </Resource> |
| <!-->]]><
We have automated heart beat monitors which checks the health of the servers and a number of background tasks. In addition to checking the list of known tasks database read & write actions are performed and the available disk space is checked. If the heart beat monitor itself takes more than 5 minutes to run an alert is sent. The heart beat monitor runs every 15 minutes.
The list of tasks that the system will monitor are defined in the class DBTask.
A task is defined by:-
Each server has it's own set of logs including:-
All the logging is configured via log4j
Email alerts for serious errors are sent automatically via a Log4J delayed SMTP append-er which will batch errors into one email if more than one per minute was to be generated.
We normally use our own in-house development servers, as they are already setup and configured to our solution server requirements it is cost effective and efficient.
For production environments we we recommend a HA Server Cluster. A minimum of two servers would be configured in a high availability fashion so that you can kill one and the outside world would not know. http://www.stsoftware.com.au/site/ST/blog/article/how-to-configure-load-balancer-/
Two client facing servers allows us to do a rolling restart.
The level of Disaster Recovery environment we can provide is only limited by client need and cost. As a minimum standard DR we have a 2 hour hardware replacement guarantee from the hosting provider and the system is backed up off site. The next level of DR would require 4 servers at a minimum.
The backups ( quite expensive half the cost of the server itself) are off site and kept for 1 week.
The system itself records every change ever made, we can tell which user changed which fields/values from the beginning of time. This is done by having a live and delta tables. We can view record sets at any point of time.
For the staging we recommend using our existing servers. When we do an install, it's a complete clean install and we copy the configuration from the previous release. With two ( or more ) client facing servers we can do a rolling restart without a noticeable outage. We can fall back to the previous release by changing the symbolic link and restart. The application database ( not client data) and full source code is included in the install.
Best practice network design for a highly scalable, distributed web system has:-
( source diagram)
The DNS for yoursite will have two (or more) IP addresses, one for each web server. This is known as a DNS round robin
We also define a direct access host name per server for health monitoring.
Example configuration for yoursite.com
Ideally the static IP of one server would be from one network provider and the other server IP would be from another network provider. This means we are not reliant on one network provider.
The firewall only allows the ports HTTP & HTTPS (80 & 443) through to web servers in the DMZ, all other ports are closed.
The firewall is the first line of defence from a DOS attack the firewall will be configured to drop concurrent requests from one IP if a threshold is exceeded. We recommend 50 concurrent requests from one IP to be a reasonable limit. Given that one browser will only make 3 or 4 concurrent requests but users behind a proxy will be seen as one IP address. A limit of 50 allows for a staff meeting at your local Starbucks but still protect against a simple single node DOS attack.
See sample configuration of iptables to prevent DOS attacks.
We install the package “fail2ban” with a custom configuration script which monitors the web server access logs for well known hack attempts. When a hack attempt is detected the IP address of the hackers system is automatically blocked for 10 minutes.
Please note: The “fail2ban” module will need to be disabled when/if penetration testing (PENTEST) is being performed as the tester will be locked out as soon as they run a script looking for well known issues.
The web server run by a low permissioned user "webapps". The DMZ firewall has redirected the high permissioned ports from HTTP/ HTTPS ( 80 & 443) to a low permissioned port for example 8080 & 8443. The low permissioned user "webapps" has a group of "nobody".
The web server can only access the data, files and message server through the "green zone firewall".
The servers in the DMZ do not store ANY client data or files. They can be restored from backup or completely rebuilt without the loss of any client data. The DMZ servers are considered "disposable", the web servers have as much CPU and cache as possible, and the disk space is only used for caching reasons.
All Linux servers are locked down to the best industry standard.
The "green zone firewall" will be configured to open the database, message server ( port 61616) and SFTP (22 port) from the DMZ to the "green zone" storage servers.
The storage servers is where the data is stored and must be backed up as regularly as possible, the disk drives must be as reliable as possible, the web servers cache the files as required so disk speed isn't a large concern.
The JMS servers are configured with failover transport with a bridged connection between the two JMS servers. The definition of the JMS server is entered into the aspc_master database in the table aspc_server.
The application worker process for all background events processing.
The actual database storage. The database is set up with "Multi-master replication" with ZERO latency or in a traditional Master slave replication.
To date the only database tested and supported Multi-master replication is Oracle RAC. The system relies heavily on optimistic locking to handle multi-server bidding and processing, it is very important that the database is 100% ACID with no latency conditions. If the link between data centers goes down ( last remaining single point of failure) we need to take one of the data centres off line and then tell Oracle RAC not to sync. When the link between data centers is back up and running then we need to do a full backup restore to the database that was off line.
Our system relies heavily on the consistency of the database. We ask questions like "what is the next invoice number?" we can't have the same invoice number been given to two application servers no matter what. This is quite a complex task for multiple master database replication.
For other supported databases (Postgres,MSSQL or MySQL) a traditional Master-Slave database replication is supported. This configuration does mean that there is the need for manual intervention to swap from the master database to the slave database in case of outage.
Note: There are cheaper database solutions that claim multiple master replication but there is qualifiers around the word "ACID". If there is any qualifiers on the word ACID we don't support it.
All raw files which are compressed and encrypted are stored on a series of SFTP servers. The default file server which is defined in the aspc_master database in the table aspc_server table will be defined to have the connection details for both file servers. When a new file is uploaded to one of the web server, the web server tries to write to both file servers. As long as the write to one file server is successful then the client file upload is treated as successful.
There is a periodic task to sync any file that was successfully upload to one file server to the other. The system will automatically heal a file server that has a missing raw file as the missing files are discovered. This allows a file server to be recovered from backup as long as the redundant server has the full set of files since the backup being restored.
Web Frameworks used:-
Server frameworks:-
Build control:-
Normal users are restricted to view only their own session details. Administrators may see the session details for all users.
Active sessions can be forcibly logged out from the session details screen. The list of active sessions for a user can be viewed from the "My Setup" screen.
Any field in the system can be marked as "searchable" which will then allow the system to search on these fields in a high performance manner as they will be automatically indexed. Any field can be searched on but without an index so slower.
Automatically generated screen based on the data model and the fields marked as "searchable".
You can select a PayPal account or create a new PayPal account
By checking "Use Live PayPal Server" checkbox, all purchases from the store will be real money transactions, uncheck this checkbox to use PayPal sendbox server (test server), no real money transfered.
To obtaining your PayPal API signature credentials, please refer Creating and Managing Classic API Credentials
PS: please clone the template-store site and call it "store" for your online store
The changes to the system have been broad over the 18 months development period.
Access Control Limits (ACLs) are the expression of the systems information security policies, they can be complex in their nature and vital to not only be correct but also to be seen as correct. The ACLs sanity checks allow for this business level visibility to the information security policies.
All sanity checks in the base product are run as part of the system build process which does not proceed if there are any failures.
The sanity checks allow for dummy data to be generated ( but not saved) and the current ACLs are checked against this dummy data.
The sanity check cases can be marked as expecting a certain number of rows to be returned by a query or to expect ( or not) an access exception if an modification is made.
Each sanity case allows a dummy login to be created as part of the sanity check at a certain access level and for the dummy person to be a member of a set of groups.
More complex set ups of clients can be done in the setup SQL using the special variables ${LOGIN_ID} and ${PERSON_ID}.
SSL is secure socket layer ie. HTTPS:// instead of HTTP://
Every web page that is sent via HTTP:// is in plan text and can easily be intercepted or even changed via what is know as "man in the middle" or "man on the side" attacks.
Mobile network provides often "improve" HTTP web pages by injecting their own scripts & images, often these unwanted "improvements" break the page being served. HTTPS prevents the carriers from being able to inject their own content.
Even when you only access the system via an intranet the setting up SSL is so simple and really is the FIRST step in any security that it's almost a mandatory step.
The old argument against httpS:// was that it was slower but that was in the days of slow machines how in many cases httpS:// is actually faster because of the hard work Google has done improving httpS:// as there is no method of securing http:// the protocol hasn't been enhance.
For a performance comparison ( most favourable to HTTPS ) see httpvshttps.com/
Below are the standard JVM server parameters.
DO NOT over tune the G1GC by setting -XX:NewSize=512m -XX:MaxNewSize=512m -XX:SurvivorRatio=2
To set up a new API key for a ReST service:-
The demonstration system can be used to try out the ReST services.
https://demo2.jobtrack.com.au/magic/3101/A5AE-9806
There are many modules enabled by default. This leads to screen clutter. Disabling the modules that are not used will lead to less user confusion and screen clutter.
Navigate to "Admin->Settings-Modules"
Disable the module
Refresh task screen and the "Timesheet" tab will be gone
Mark the menu as "Inactive"
Refresh menu ( "QuickStart" will be hidden)
To enable spell checker, the package 'aspell' needs to be installed on the server side. TinyMCE calls a web service 'v1/spell' to check spelling and store words in the user's dictionary.
When the user clicks the spell check button the text is sent to the server via the web service 'v1/spell' and resulting errors and suggestions are sent back and highlighted for the user.
A web service "v1/spell" allows for the checking of misspelled words and maintenance of the user's private dictionary.
sudo apt-get install aspell
The user's timezone can't be detected by a ReST call itself.
The client's public IP addresses we can be used in combination with freegeoip.net ReST service to find a rough location.
When a client logs into the system, the client's timezone is passed as a parameter in the ReST call /v1/auth/login/{username}.
The web pages that use the library jstz to detect the timezone and then does log-in via ReST. We remember the user's timezone in the database session record.
All the data from a stSoftware server can be fetched via the standard ReST API, all the standard ACLs and validation rules are applied whether the data is access via the standard screens or via the ReST API
Click here to download an example Excel spread sheet which shows how to fetch data from an ST Server into Excel.
1. Open spreadsheet and click "Enable Macros".
2. Click "add-ins" menus
3. Click "Login" icon
4. Enter connection details
Enter the connection details for your own server or use one of the demo systems by using the host https://demo2.jobtrack.com.au and the user name user with the password user
Please note the demo servers are reset daily ( don't store anything you want to keep).
5. Click on the query button
6. Enter the fields, class and filer for the data to be fetched.
There are a number of predefined templates which can be chosen or enter the fields "Class", "Fields" and "Where" directly.
The standard email gateway for sending emails is Amazon Simple Email Service
If your domain has configured an SPF record you will need to include the domain amazonses.com
For example:-
"v=spf1 include:amazonses.com -all"
.png "iphone login")