Qualitätssicherung Digitale/Web Projekte - Revision history

David Smith: /* Cross-Browser Support and Testing */

2016-07-01T09:34:44Z

Cross-Browser Support and Testing

New page

== Frontend Code Guidelines ==

=== Indentations ===
For all languages, regardless of complexity or age, it is recommended that soft tabs are used. Soft tabs are where space characters are used rather than tab characters and upon hitting the tab key, your editor of choice should insert four spaces.

=== Cross-Browser Support and Testing ===
Generally, it is expected for you to support the following internet browsers (for desktops, tablets and mobiles - where possible):

* Google Chrome (current version plus 1 previous version)
* Mozilla Firefox (current version plus 1 previous version)
* Safari (current version plus 1 previous version)
* Internet Explorer 10+

Please note that the above browsers must be tested on both Microsoft Windows and Apple OS X. Special consideration for Linux machines is not mandatory, however if time permits, is also encouraged.

=== HTML5 ===
Markup code should adhere to the W3C Standards (http://www.w3.org/TR/html5/) and should be able to pass, at least 90%, validation by the W3C Validation Service (https://validator.w3.org/). We do not strive for 100% as cross-browser compatibility is more important than passing validation tests. It is acceptable for you to write a non-standards chunk of code if the result is beneficial to the goal of supporting different browsers and devices.

=== CSS ===
All CSS should be included within each page of your website from an external stylesheet and should never be delivered via inline CSS. Additionally, it is recommended that Print CSS styles are given sufficient attention, especially for content-heavy websites.

=== JavaScript Functionality and Anchor Links ===
It is '''never''' acceptable to have inline JavaScript embedded within the href attribute of an anchor tag. The negative impact of such inline JavaScript is great and there are no circumstances where it would be acceptable to use it.

=== Performance Testing in General ===
All websites and apps should be performance tested ''before'' being considered finished. For websites, it is expected that all developers will perform a Page Speed Insights test (https://developers.google.com/speed/pagespeed/insights/) and a GTmetrix Performance Test (http://gtmetrix.com/) and, at a minimum, the website will pass with a score/grade in the top 15%. Thus a score of 85% and a grade of A for the Google-powered and GTmetrix-powered tests respectively are required.

More information can be found here: https://wiki.parasol-island.com/Performance_of_Webpages

=== Performance Testing of CSS and JavaScript ===
All CSS and JavaScript code should be written with performance in mind. It is highly recommended to follow the Yahoo Developer Performance Guidelines for Best Practices (https://developer.yahoo.com/performance/).

=== Images Sprites ===
Where possible, it is recommended that sprites are to be used for small, similar assets (e.g. icons) to help reduce the overall page weight and lower the number of HTTP requests, thus rendering the page quicker.

=== Meta/Link Tags ===
Certain meta tags are not only important for SEO purposes but are of the utmost importance for many disabled internet users, therefore it is highly recommended that you pay close attention to your usage of meta tags. Please refer to the upcoming section titled “Accessibility” for more meta tag-related recommendations.

==== Often Forgotten or Misused Tags ====
The following tags are often forgotten or misused, therefore it is recommended that you periodically double-check that you are, in fact, using such tags correctly.

# Favicon
# Web Icons (for mobile devices)
# Basic fundamental tags (Title, Description, Keywords, Robots etc.)

Before going live with a website, it is recommended that you triple-check any usages of the robots meta tag to ensure that you have not configured the attribute to be negative towards SEO.

Here's a pretty good online service to create favicons and touch icons including the needed sourcecode: http://www.favicon-generator.org/

==== Facebook / Open Graph Tags ====
Please ensure that you have not forgotten to include, at least, the following four Open Graph tags in your code:

# OG:Image
# OG:Title
# OG:Description
# OG:URL

=== Accessibility ===
The W3C organization runs the Web Accessibility Initiative (WAI) (http://www.w3.org/WAI/) and it is very much recommended for you to familiarize yourself with this initiative as it will empower you to write code that is beneficial and usable by all internet users, including those with disabilities.

==== Viewports ====
For the viewport meta tag, it is very important that you do not set maximum-scale to 1.0 (thus rendering the zoom functionality of the mobile browser inoperable) because you will be inadvertently inflicting undeserved difficulty upon visitors of your website whom may have visual problems.

==== Fantastic Resources for Improving Accessibility ====
W3C Checklist of Checkpoints for Web Content Accessibility Guidelines (http://www.w3.org/TR/WCAG10/full-checklist.html)

=== Compulsory Legal Information ===
The following legal information is compulsory for the vast majority of websites, including some microsites (e.g. Facebook Tab apps).

In English, the compulsory legal information can be presented like so:

{Firmenname und Rechtsform}
{Strasse}
{Land}-{PLZ} {Ort}
Local Court of {Stadt}, HRB {Nummer} (Verpflichtend, wenn ein Handelsregistereintrag vorliegt)
VAT ID No.: DE{Nummer}
Telephone: +49 ({Vorwahl}) {Telefon}
E-Mail: {eMail Adresse}
Managing Director and responsible under Sec. 55 para. (2) RStV: {Name/n Geschäftsführer}

Similarly, in German, the compulsory legal information can be presented like so:

{Firmenname und Rechtsform}
{Strasse}
{Land}-{PLZ} {Ort}
Amtsgericht {Stadt}, HRB {Nummer} (Verpflichtend, wenn ein Handelsregistereintrag vorliegt)
Ust-ID Nr.: DE{Nummer}
Telefon: +49 ({Vorwahl}) {Telefon}
E-Mail: {eMail Adresse}
Geschäftsführer und inhaltlich Verantwortlicher gemäß § 55 Abs. 2 RStV: {Name/n Geschäftsführer}

==== Copyright Information ====
Please refrain from hard-coding the year value within the copyright notice; instead, please utilize auto-updating functionality. For example, with PHP, you could perform the following:

© <?php echo date("Y"); ?> {Firmenname}. Alle Rechte vorbehalten.

=== Search Engine Optimization (SEO) ===
After all of the hard work that you have invested in your code, it is very much recommended for you, when you have finished your project, to double-check that your website has a working, up-to-date sitemap so that your hard work is not negatively affected by badly-performing SEO performance.

Additionally, it is recommended to manually submit the URL of your website to Google via http://www.google.com/addurl/?continue=/addurl even if your website is already listed in Google SERPs.

As a developer, it is often quite easy to overlook the markup hierarchy of a page. Therefore, it is recommended for you to perform a post-development examination of all important tag usages. For example, ensure that heading tags have been used in a sensible manner.

==== Google Webmaster Tools ====
Please ensure that your website has been correctly setup and configured with Google Webmaster Tools and that the access to this account has been shared with the Project Manager of your project.

=== Error Pages ===
Please ensure that your website is correctly configured, and tested, to produce relevant error pages and codes for situations such as 404s and 401s. In absolutely no circumstances should the user be presented with a blank, white page.

=== Privacy ===
Almost all websites should be operable via an SSL, encrypted, connection. If your website is not utilizing an SSL certificate and you are obtaining information from your visitors, please speak with your Project Manager to discuss a plan to fix this as '''all''' private and confidential user information '''must''' be transmitted safely and securely.

=== Open Source Rules! ===
At Parasol Island, we truly believe in the open source movement and, as such, follow what we like to call, ''The Open Source Rule''. This rule depicts that all frontend-related tools be free of charge and available for everyone to use.

If, under very special circumstances, you find yourself needing to use a paid tool or service, you must ensure that the license is applicable to both yourself and Parasol Island (at no extra cost). If this is not possible, please speak to your Project Manager as a matter of urgency.

== Backend Code Guidelines ==

=== Wordpress Admin / phpMyAdmin / Other Administrative Control Panels ===
If your website is utilizing the ever-popular phpMyAdmin software or any other limited-access, administrative control panels (be it for databases, users, content etc.), please ensure that the path to such a feature does not include keywords that are commonly used across the internet. Usage of such common keywords will negatively impact the safety and security of your website.

For example, it is never acceptable to use the following keywords in the URL:

# phpMyAdmin
# admin
# administration
# wp-admin
# secure

It is highly recommended that you utilize random, complex strings for accessing security-sensitive areas of your website.

Additionally, it is recommended for all security-sensitive directories to utilize .htaccess/.htpasswd files to integrate a two-step verification process.

=== Web Servers ===

==== General ====
NGINX or LightHTTPD is very much preferred with only ports 80 and 443 open by default; all other ports should be closed. Please also ensure that FTP access is disabled.

==== SSL ====
All personally-identifiable and confidential information obtained from visitors (via any means) must be transmitted through a correctly-configured SSL connection using a validated and active SSL Certificate.

==== Database Encryption & Decryption ====
All identifiable information that is to be stored in a database (or any other method of storage) must be encrypted at source and decrypted when needed.

==== Multiviews ====
Multiviews '''must''' always be disabled.

=== Database Servers ===
Where possible, a project should utilize a dedicated database server which has a very tightly controlled firewall configured. Ideally, the firewall would only permit connections to be made to the database server from your project’s web server, thus making the database server inaccessible to the rest of the world.

=== PHP ===

==== Environment ====
By default, PHP should be operating in Safe Mode and allow_url_fopen should be Off. Additionally, passwords should not be stored in cleartext within the PHP files containing business-logic. Passwords and other security-centric data should be stored in an external configuration file and stored in a non publicly-available location (outside of the server’s web-root).

==== User Input, Sanitization and XSS ====
Any information obtained from visitors must be sanitized and stored securely. Under the vast majority of circumstances, you should strip all tags from visitor input. Where possible, the visitor’s inputted data should not be entered directly into the database (or any other method of storage). For example, if you have a gender <select> element where only Mr, Mrs and Miss are the potential options, it is recommended that you compare the visitor’s input and then store your own value into the database. This approach of comparing and accepting, results in much safer input handling as you are able to better govern acceptable user values.

Additionally, it is critical that you only utilize user-sourced data within contained and controlled environments. For example, if you are running a competition to guess the number of balloons in a box, not only should you check that the user’s submitted guess is of numerical value '''before''' storing it in a database and that the accommodating database field is of an integer-based field type, but you should also '''force''' any future variables which handle the guess data to be of an integer-based type, too.

This two-staged governance approach provides much more protection against dangerous XSS attacks than simply accepting and using any type of data.

==== CSRF (Cross-Site Request Forgery / “Session Riding”) Attacks ====
If your websites accepts data or actions from its visitors, you must protect against CSRF attacks by utilizing CSRF session tokens or cookies (or both). If you are not familiar with CSRF attacks, here is a simple example that illustrates the danger of such attacks:

===== CSRF Example =====
Imagine your website requires its visitors to create a premium (paid) account in order to access special content. As the developer, you have created a file named delete-account.php because, quite rightly, you are aware that users of your website should always have the option of deleting their own accounts. This sort of innocent functionality can easily be abused by an CSRF attack if you do not protect against it.

How? Quite simply, an attacker could create a link on a popular forum, that many of your visitors use, that links to your delete-account.php page and once the user clicks on the unsuspicious forum link, they suddenly find themselves with a deleted account on your website.

===== Protection Against CSRF Attacks =====
The simplest and easiest way to protect your website against a CSRF attack is to create a unique session variable when your visitor first visits your website and whenever they want to perform an account (such as creating or deleting an account), you send this unique identifier along with their request (be it via a hidden input, query string value etc.) which you can compare against the value stored in their session variable. If the two values match, go ahead and process their request. If they do not, do not process the request.

If we go back to our previous example (with our delete-account.php file), we can see that by requiring the CSRF token to be passed with the call (e.g. delete-account.php?csrfToken=5ghfido943zqs95akopq19gfsa), any forged link on a forum would not actually be able to delete the user’s account as it would not be able to pass the correct CSRF token. Additionally, by storing the CSRF token in the user’s session, they will receive a new token when their session expires.

=== Load Testing ===
We recommend using the following service to load-test your website/application: https://app.loadimpact.com

=== Open Source Rules! ===
At Parasol Island, we truly believe in the open source movement and, as such, follow what we like to call, The Open Source Rule. This rule depicts that all backend-related tools be free of charge and available for everyone to use.

If, under very special circumstances, you find yourself needing to use a paid tool or service, you must ensure that the license is applicable to both yourself and Parasol Island (at no extra cost). If this is not possible, please speak to your Project Manager as a matter of urgency.

David Smith at 09:45, 23 July 2015

2015-07-23T09:45:26Z

← Older revision		Revision as of 09:45, 23 July 2015
Line 91:		Line 91:
	Please refrain from hard-coding the year value within the copyright notice; instead, please utilize auto-updating functionality. For example, with PHP, you could perform the following:		Please refrain from hard-coding the year value within the copyright notice; instead, please utilize auto-updating functionality. For example, with PHP, you could perform the following:

	© <?php date("Y"); ?> {Firmenname}. Alle Rechte vorbehalten.		© <?php echo date("Y"); ?> {Firmenname}. Alle Rechte vorbehalten.

	=== Search Engine Optimization (SEO) ===		=== Search Engine Optimization (SEO) ===

David Smith at 09:14, 17 June 2015

2015-06-17T09:14:47Z

← Older revision		Revision as of 09:14, 17 June 2015
Line 177:		Line 177:

	=== Open Source Rules! ===		=== Open Source Rules! ===
	At Parasol Island, we truly believe in the open source movement and, as such, follow what we like to call, The Open Source Rule. This rule depicts that all ~~frontend~~-related tools be free of charge and available for everyone to use.		At Parasol Island, we truly believe in the open source movement and, as such, follow what we like to call, The Open Source Rule. This rule depicts that all backend-related tools be free of charge and available for everyone to use.

	If, under very special circumstances, you find yourself needing to use a paid tool or service, you must ensure that the license is applicable to both yourself and Parasol Island (at no extra cost). If this is not possible, please speak to your Project Manager as a matter of urgency.		If, under very special circumstances, you find yourself needing to use a paid tool or service, you must ensure that the license is applicable to both yourself and Parasol Island (at no extra cost). If this is not possible, please speak to your Project Manager as a matter of urgency.

David Smith at 06:32, 17 June 2015

2015-06-17T06:32:05Z

← Older revision		Revision as of 06:32, 17 June 2015
Line 98:		Line 98:
	Additionally, it is recommended to manually submit the URL of your website to Google via http://www.google.com/addurl/?continue=/addurl even if your website is already listed in Google SERPs.		Additionally, it is recommended to manually submit the URL of your website to Google via http://www.google.com/addurl/?continue=/addurl even if your website is already listed in Google SERPs.

	As a developer, it is often quite easy to overlook the markup hierarchy of a page. Therefore, it is recommended for you to perform a post-development examination of all important tag usages. For example, ensure that heading tags ~~(<h1>, <h2> etc.)~~ have been used in a sensible manner.		As a developer, it is often quite easy to overlook the markup hierarchy of a page. Therefore, it is recommended for you to perform a post-development examination of all important tag usages. For example, ensure that heading tags have been used in a sensible manner.

	==== Google Webmaster Tools ====		==== Google Webmaster Tools ====

David Smith at 06:31, 17 June 2015

2015-06-17T06:31:31Z

Show changes

David Smith at 06:21, 17 June 2015

2015-06-17T06:21:03Z

← Older revision		Revision as of 06:21, 17 June 2015
Line 17:		Line 17:
	Markup code should adhere to the W3C Standards (http://www.w3.org/TR/html5/) and should be able to pass, at least 90%, validation by the W3C Validation Service (https://validator.w3.org/). We do not strive for 100% as cross-browser compatibility is more important than passing validation tests. It is acceptable for you to write a non-standards chunk of code if the result is beneficial to the goal of supporting different browsers and devices.		Markup code should adhere to the W3C Standards (http://www.w3.org/TR/html5/) and should be able to pass, at least 90%, validation by the W3C Validation Service (https://validator.w3.org/). We do not strive for 100% as cross-browser compatibility is more important than passing validation tests. It is acceptable for you to write a non-standards chunk of code if the result is beneficial to the goal of supporting different browsers and devices.

			=== CSS ===
			All CSS should be included within each page of your website from an external stylesheet and should never be delivered via inline CSS. Additionally, it is recommended that Print CSS styles are given sufficient attention, especially for content-heavy websites.

			=== JavaScript Functionality and Anchor Links ===
			It is '''never''' acceptable to have inline JavaScript embedded within the href attribute of an anchor tag. The negative impact of such inline JavaScript is great and there are no circumstances where it would be acceptable to use it.

			=== Performance Testing in General ===
			All websites and apps should be performance tested ''before'' being considered finished. For websites, it is expected that all developers will perform a Page Speed Insights test (https://developers.google.com/speed/pagespeed/insights/) and a GTmetrix Performance Test (http://gtmetrix.com/) and, at a minimum, the website will pass with a score/grade in the top 15%. Thus a score of 85% and a grade of A for the Google-powered and GTmetrix-powered tests respectively are required.

			More information can be found here: https://wiki.parasol-island.com/Performance_of_Webpages

			=== Performance Testing of CSS and JavaScript ===
			All CSS and JavaScript code should be written with performance in mind. It is highly recommended to follow the Yahoo Developer Performance Guidelines for Best Practices (https://developer.yahoo.com/performance/).

			=== Images Sprites ===
			Where possible, it is recommended that sprites are to be used for small, similar assets (e.g. icons) to help reduce the overall page weight and lower the number of HTTP requests, thus rendering the page quicker.

			=== Meta/Link Tags ===
			Certain meta tags are not only important for SEO purposes but are of the utmost importance for many disabled internet users, therefore it is highly recommended that you pay close attention to your usage of meta tags. Please refer to the upcoming section titled “Accessibility” for more meta tag-related recommendations.

			==== Often Forgotten or Misused Tags ====
			The following tags are often forgotten or misused, therefore it is recommended that you periodically double-check that you are, in fact, using such tags correctly.

			# Favicon
			# Web Icons (for mobile devices)
			# Basic fundamental tags (Title, Description, Keywords, Robots etc.)

			Before going live with a website, it is recommended that you triple-check any usages of the robots meta tag to ensure that you have not configured the attribute to be negative towards SEO.

			==== Facebook / Open Graph Tags ====
			Please ensure that you have not forgotten to include, at least, the following four Open Graph tags in your code:

			# OG:Image
			# OG:Title
			# OG:Description
			# OG:URL

			=== Accessibility ===
			The W3C organization runs the Web Accessibility Initiative (WAI) (http://www.w3.org/WAI/) and it is very much recommended for you to familiarize yourself with this initiative as it will empower you to write code that is beneficial and usable by all internet users, including those with disabilities.

			==== Viewports ====
			For the viewport meta tag, it is very important that you do not set maximum-scale to 1.0 (thus rendering the zoom functionality of the mobile browser inoperable) because you will be inadvertently inflicting undeserved difficulty upon visitors of your website whom may have visual problems.

			==== Fantastic Resources for Improving Accessibility ====
			W3C Checklist of Checkpoints for Web Content Accessibility Guidelines (http://www.w3.org/TR/WCAG10/full-checklist.html)

			=== Compulsory Legal Information ===
			The following legal information is compulsory for the vast majority of websites, including some microsites (e.g. Facebook Tab apps).

			In English, the compulsory legal information can be presented like so:

			{Firmenname und Rechtsform}
			{Strasse}
			{Land}-{PLZ} {Ort}
			Local Court of {Stadt}, HRB {Nummer} (Verpflichtend, wenn ein Handelsregistereintrag vorliegt)
			VAT ID No.: DE{Nummer}
			Telephone: +49 ({Vorwahl}) {Telefon}
			E-Mail: {eMail Adresse}
			Managing Director and responsible under Sec. 55 para. (2) RStV: {Name/n Geschäftsführer}

			Similarly, in German, the compulsory legal information can be presented like so:

			{Firmenname und Rechtsform}
			{Strasse}
			{Land}-{PLZ} {Ort}
			Amtsgericht {Stadt}, HRB {Nummer} (Verpflichtend, wenn ein Handelsregistereintrag vorliegt)
			Ust-ID Nr.: DE{Nummer}
			Telefon: +49 ({Vorwahl}) {Telefon}
			E-Mail: {eMail Adresse}
			Geschäftsführer und inhaltlich Verantwortlicher gemäß § 55 Abs. 2 RStV: {Name/n Geschäftsführer}

			==== Copyright Information ====
			Please refrain from hard-coding the year value within the copyright notice; instead, please utilize auto-updating functionality. For example, with PHP, you could perform the following:

			* © <?php date("Y"); ?> {Firmenname}. Alle Rechte vorbehalten.

David Smith at 06:11, 17 June 2015

2015-06-17T06:11:10Z

← Older revision		Revision as of 06:11, 17 June 2015
Line 5:		Line 5:

	=== Cross-Browser Support and Testing ===		=== Cross-Browser Support and Testing ===

	Generally, it is expected for you to support the following internet browsers (for desktops, tablets and mobiles - where possible):		Generally, it is expected for you to support the following internet browsers (for desktops, tablets and mobiles - where possible):

Line 14:		Line 13:

	Please note that the above browsers must be tested on both Microsoft Windows and Apple OS X. Special consideration for Linux machines is not mandatory, however if time permits, is also encouraged.		Please note that the above browsers must be tested on both Microsoft Windows and Apple OS X. Special consideration for Linux machines is not mandatory, however if time permits, is also encouraged.

			=== HTML5 ===
			Markup code should adhere to the W3C Standards (http://www.w3.org/TR/html5/) and should be able to pass, at least 90%, validation by the W3C Validation Service (https://validator.w3.org/). We do not strive for 100% as cross-browser compatibility is more important than passing validation tests. It is acceptable for you to write a non-standards chunk of code if the result is beneficial to the goal of supporting different browsers and devices.




	=Meta Angaben und Informationen=		=Meta Angaben und Informationen=

David Smith at 06:10, 17 June 2015

2015-06-17T06:10:24Z

← Older revision		Revision as of 06:10, 17 June 2015
Line 4:		Line 4:
	For all languages, regardless of complexity or age, it is recommended that soft tabs are used. Soft tabs are where space characters are used rather than tab characters and upon hitting the tab key, your editor of choice should insert four spaces.		For all languages, regardless of complexity or age, it is recommended that soft tabs are used. Soft tabs are where space characters are used rather than tab characters and upon hitting the tab key, your editor of choice should insert four spaces.

	Cross-Browser Support and Testing		=== Cross-Browser Support and Testing ===

	Generally, it is expected for you to support the following internet browsers (for desktops, tablets and mobiles - where possible):		Generally, it is expected for you to support the following internet browsers (for desktops, tablets and mobiles - where possible):

	~~'''<br>~~
	~~'''~~
	* Google Chrome (current version plus 1 previous version)		* Google Chrome (current version plus 1 previous version)
	* Mozilla Firefox (current version plus 1 previous version)		* Mozilla Firefox (current version plus 1 previous version)

David Smith at 06:08, 17 June 2015

2015-06-17T06:08:49Z

← Older revision		Revision as of 06:08, 17 June 2015
Line 1:		Line 1:
			== Frontend Code Guidelines ==

			=== Indentations ===
			For all languages, regardless of complexity or age, it is recommended that soft tabs are used. Soft tabs are where space characters are used rather than tab characters and upon hitting the tab key, your editor of choice should insert four spaces.

			Cross-Browser Support and Testing

			Generally, it is expected for you to support the following internet browsers (for desktops, tablets and mobiles - where possible):

			'''<br>
			'''
			* Google Chrome (current version plus 1 previous version)
			* Mozilla Firefox (current version plus 1 previous version)
			* Safari (current version plus 1 previous version)
			* Internet Explorer 9+

			Please note that the above browsers must be tested on both Microsoft Windows and Apple OS X. Special consideration for Linux machines is not mandatory, however if time permits, is also encouraged.

	=Meta Angaben und Informationen=		=Meta Angaben und Informationen=

David Smith: /* Webapp */

2015-04-30T09:30:23Z

Webapp

← Older revision		Revision as of 09:30, 30 April 2015
Line 338:		Line 338:

	- XSS unterbinden (<script>alert(XXS)</script>)		- XSS unterbinden (<script>alert(XXS)</script>)

			TODO: Bigger focus on XSS (CSRF tokens etc.)

	==CMS==		==CMS==