Simplified HTTPS Configuration - Revision history

Drn@ecs.soton.ac.uk at 08:46, 20 May 2022

2022-05-20T08:46:00Z

← Older revision		Revision as of 08:46, 20 May 2022
Line 1:		Line 1:
	[[Category:Howto]]		[[Category:Howto]]

	''' * * * YOU MUST USE EPRINTS 3.4.1+ FOR THE CONFIGURATION BELOW TO WORK RELIABLY* * *'''. For earlier versions of EPrints there is a more complex [[Legacy HTTPS Configuration]].		''' * * * YOU MUST USE EPRINTS 3.4.1+ FOR THE CONFIGURATION BELOW TO WORK RELIABLY* * *'''. For earlier versions of EPrints there is a more complex [[Legacy HTTPS Only Configuration]].

	Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongst other problems. In EPrints 3.4.1 the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's <code>cfg/cfg.d/10_core.pl</code> in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.		Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongst other problems. In EPrints 3.4.1 the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's <code>cfg/cfg.d/10_core.pl</code> in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.

Drn@ecs.soton.ac.uk: Added link to Legacy HTTPS configuration.

2022-05-20T08:15:03Z

Added link to Legacy HTTPS configuration.

← Older revision		Revision as of 08:15, 20 May 2022
Line 1:		Line 1:
	[[Category:Howto]]		[[Category:Howto]]

	''' * * * YOU MUST USE EPRINTS 3.4.1+ FOR THE CONFIGURATION BELOW ~~TO BE GUARANTEED~~ TO WORK * * *'''		''' * * * YOU MUST USE EPRINTS 3.4.1+ FOR THE CONFIGURATION BELOW TO WORK RELIABLY* * *'''. For earlier versions of EPrints there is a more complex [[Legacy HTTPS Configuration]].

	Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongst other problems. In EPrints 3.4.1 the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's <code>cfg/cfg.d/10_core.pl</code> in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.		Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongst other problems. In EPrints 3.4.1 the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's <code>cfg/cfg.d/10_core.pl</code> in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.

Drn@ecs.soton.ac.uk: Howto not authentication category

2022-03-15T16:42:19Z

Howto not authentication category

← Older revision		Revision as of 16:42, 15 March 2022
Line 1:		Line 1:
	[[Category:~~Authentication~~]]		[[Category:Howto]]

	''' * * * YOU MUST USE EPRINTS 3.4.1+ FOR THE CONFIGURATION BELOW TO BE GUARANTEED TO WORK * * *'''		''' * * * YOU MUST USE EPRINTS 3.4.1+ FOR THE CONFIGURATION BELOW TO BE GUARANTEED TO WORK * * *'''

Drn@ecs.soton.ac.uk: /* Issues and Troubleshooting */

2022-03-15T16:40:36Z

Issues and Troubleshooting

@@ Line 33: / Line 33: @@
 == Issues and Troubleshooting ==
 Inevitably you may still encounter issues even if you use one of the configurations above, so it is advised you test this on a development or pre-production instance of your repository to check you get the behaviour you expect.
 === EPrint URI Change ===
@@ Line 52: / Line 72: @@
 OAI-PMH (e.g. <nowiki>http://example.eprints.org/cgi/oai2</nowiki> and <nowiki>https://example.eprints.org/cgi/oai2</nowiki>) provide different relations (http or https) for a publication but the OAI identifier is protocol independent and therefore stays the same.  Therefore, third party applications that make use of OAI-PMH should not be affected if they harvest as the protocol specifies.

Drn@ecs.soton.ac.uk: /* Bazaar Plugins */

2022-03-15T16:39:13Z

Bazaar Plugins

← Older revision		Revision as of 16:39, 15 March 2022
Line 54:		Line 54:

	=== Bazaar Plugins ===		=== Bazaar Plugins ===
	Effort has been taken to resolve any issues as a result of <tt>$c->{host}</tt> no longer being defined if you want to use HTTPS everywhere (with HTTPS redirects). However, this can only be done to the extent of the core codebase. Some [https://bazaar.eprints.org/ Bazaar]] plugins may rely on <tt>$c->{host}</tt> being defined. Below are the Bazaar plugins we are aware have issues. This list is not exhaustive.		Effort has been taken to resolve any issues as a result of <tt>$c->{host}</tt> no longer being defined if you want to use HTTPS everywhere (with HTTPS redirects). However, this can only be done to the extent of the core codebase. Some [https://bazaar.eprints.org/ Bazaar] plugins may rely on <tt>$c->{host}</tt> being defined. Below are the Bazaar plugins we are aware have issues. This list is not exhaustive.

	==== [http://bazaar.eprints.org/379/ Repository Links Plugin] ====		==== [http://bazaar.eprints.org/379/ Repository Links Plugin] ====

Drn@ecs.soton.ac.uk: Added general point about Bazaar plugins.

2022-03-15T16:38:24Z

Added general point about Bazaar plugins.

← Older revision		Revision as of 16:38, 15 March 2022
Line 53:		Line 53:
	OAI-PMH (e.g. <nowiki>http://example.eprints.org/cgi/oai2</nowiki> and <nowiki>https://example.eprints.org/cgi/oai2</nowiki>) provide different relations (http or https) for a publication but the OAI identifier is protocol independent and therefore stays the same. Therefore, third party applications that make use of OAI-PMH should not be affected if they harvest as the protocol specifies.		OAI-PMH (e.g. <nowiki>http://example.eprints.org/cgi/oai2</nowiki> and <nowiki>https://example.eprints.org/cgi/oai2</nowiki>) provide different relations (http or https) for a publication but the OAI identifier is protocol independent and therefore stays the same. Therefore, third party applications that make use of OAI-PMH should not be affected if they harvest as the protocol specifies.

	=== [http://bazaar.eprints.org/379/ Repository Links Plugin] ===		=== Bazaar Plugins ===
			Effort has been taken to resolve any issues as a result of <tt>$c->{host}</tt> no longer being defined if you want to use HTTPS everywhere (with HTTPS redirects). However, this can only be done to the extent of the core codebase. Some [https://bazaar.eprints.org/ Bazaar]] plugins may rely on <tt>$c->{host}</tt> being defined. Below are the Bazaar plugins we are aware have issues. This list is not exhaustive.

			==== [http://bazaar.eprints.org/379/ Repository Links Plugin] ====
	The Repository Links plugin uses the EPrints URL to lookup where it is used on other repositories. If your repository is configured as one of the remote repositories, then the master repository will have been storing your repository URLs as HTTP up to the point you switch over to [[Simplified_HTTPS_Configuration#HTTPS_Only \| HTTPS Only]]. When you do this it will start recording these URLs as HTTPS.		The Repository Links plugin uses the EPrints URL to lookup where it is used on other repositories. If your repository is configured as one of the remote repositories, then the master repository will have been storing your repository URLs as HTTP up to the point you switch over to [[Simplified_HTTPS_Configuration#HTTPS_Only \| HTTPS Only]]. When you do this it will start recording these URLs as HTTPS.

Drn@ecs.soton.ac.uk: Added section about RepoLinks plugin.

2021-12-16T11:40:50Z

Added section about RepoLinks plugin.

← Older revision		Revision as of 11:40, 16 December 2021
Line 52:		Line 52:

	OAI-PMH (e.g. <nowiki>http://example.eprints.org/cgi/oai2</nowiki> and <nowiki>https://example.eprints.org/cgi/oai2</nowiki>) provide different relations (http or https) for a publication but the OAI identifier is protocol independent and therefore stays the same. Therefore, third party applications that make use of OAI-PMH should not be affected if they harvest as the protocol specifies.		OAI-PMH (e.g. <nowiki>http://example.eprints.org/cgi/oai2</nowiki> and <nowiki>https://example.eprints.org/cgi/oai2</nowiki>) provide different relations (http or https) for a publication but the OAI identifier is protocol independent and therefore stays the same. Therefore, third party applications that make use of OAI-PMH should not be affected if they harvest as the protocol specifies.

			=== [http://bazaar.eprints.org/379/ Repository Links Plugin] ===
			The Repository Links plugin uses the EPrints URL to lookup where it is used on other repositories. If your repository is configured as one of the remote repositories, then the master repository will have been storing your repository URLs as HTTP up to the point you switch over to [[Simplified_HTTPS_Configuration#HTTPS_Only \| HTTPS Only]]. When you do this it will start recording these URLs as HTTPS.

			This creates two problems. '''$c->{host}''' will not longer be set and this will prevent both the related links box for Repository Links being displayed on your repository's abstract pages but also the same box being displayed for the abstract pages for items on the master repository. To fix this you will need to update '''$c->{host}''' to '''$c->{securehost}''' in '''/cgi/get_repo_links''' so the hostname will not be set in the request sent to the master repository.

			Also. the protocol itself needs to be updated to '''https''' from '''http''' in the text that proceeds '''$c->{host}''' in the same file. This will ensure that it looks for https URLs which will now be stored on the master repository. However, the master repository will still be storing http URLs for old items, so they will need to update all the URLs for your reposotory to https URLs to make the Repository Links related links box work on your repository, although the first change you fix the missing related links box on the master repository.

			It is also probably worth updating the protocol used for making HTTP requests to the master repository to use https as well, assuming it is configured to support HTTPS.

			It is unclear if and what changes would be necessary if your repository is the master repository for the Repository Links plugin. However, as a minimum you should make the changes described above and check any other Repository Link plugin files for the use of '''$c->{host}''' to '''$c->{securehost}''' and ensure the https is used as the protocol wherever http is currently being used.

	=== Search Engine Indexing ===		=== Search Engine Indexing ===

Drn@ecs.soton.ac.uk at 07:30, 27 October 2020

2020-10-27T07:30:19Z

← Older revision		Revision as of 07:30, 27 October 2020
Line 1:		Line 1:
	[[Category:Authentication]]		[[Category:Authentication]]

	''' * * * YOU MUST USE EPRINTS 3.4.1++ FOR THE CONFIGURATION BELOW TO BE GUARANTEED TO WORK * * *'''		''' * * * YOU MUST USE EPRINTS 3.4.1+ FOR THE CONFIGURATION BELOW TO BE GUARANTEED TO WORK * * *'''

	Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongst other problems. In EPrints 3.4.1 the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's <code>cfg/cfg.d/10_core.pl</code> in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.		Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongst other problems. In EPrints 3.4.1 the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's <code>cfg/cfg.d/10_core.pl</code> in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.

Th.lauke@arcor.de: typos corrected, formatting improved

2019-08-06T13:55:55Z

typos corrected, formatting improved

← Older revision		Revision as of 13:55, 6 August 2019
Line 1:		Line 1:
	~~''' * * * YOU MUST USE EPRINTS 3.4.1 OR GREATER FOR THE CONFIGURATION BELOW TO BE GUARANTEED TO WORK * * *'''~~		[[Category:Authentication]]

	Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, ~~amongsot~~ other problems. In EPrints 3.4.1+ the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's ~~'''~~cfg/cfg.d/10_core.pl~~'''~~ in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.		''' * * * YOU MUST USE EPRINTS 3.4.1++ FOR THE CONFIGURATION BELOW TO BE GUARANTEED TO WORK * * *'''

			Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongst other problems. In EPrints 3.4.1 the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's <code>cfg/cfg.d/10_core.pl</code> in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.

	== Configurations ==		== Configurations ==
	'''Make sure you remove or ~~disabled~~ your archive's ''cfg/cfg.d/https.pl'' if it exists as it may override ~~these~~ configuration below. Once you have updated your configuration you must run ''generate_apacheconf'' to regenerate configuration for Apache before restarting the web server.'''		'''Make sure you remove or disable your archive's <code>cfg/cfg.d/https.pl</code> if it exists as it may override the configuration below. Once you have updated your configuration you must run <code>generate_apacheconf</code> to regenerate configuration for Apache before restarting the web server.'''

	=== HTTP Only ===		=== HTTP Only ===
	It is advised you avoid using this configuration unless you developing a repository on a non-publicly accessible web host.		It is advised you avoid using this configuration unless you are developing a repository on a non-publicly accessible web host.
	$c->{host} = 'example.eprints.org';		$c->{host} = 'example.eprints.org';
	$c->{port} = 80;		$c->{port} = 80;
Line 14:		Line 16:

	=== HTTPS When You Login ===		=== HTTPS When You Login ===
	This is the current default for EPrints. All publicly accessible pages will use HTTP be default (but still be accessible over HTTPS if you modify the URL) and the login page and all login restricted pages will use HTTPS or be redirected from HTTP.		This is the current default for EPrints. All publicly accessible pages will use HTTP by default (but still be accessible over HTTPS if you modify the URL) and the login page and all login restricted pages will use HTTPS or be redirected from HTTP.
	$c->{host} = 'example.eprints.org';		$c->{host} = 'example.eprints.org';
	$c->{port} = 80;		$c->{port} = 80;
Line 21:		Line 23:

	=== HTTPS Only ===		=== HTTPS Only ===
	This ~~ensure~~ that ~~now~~ page (image, CSS, JavaScript file, etc.) will be ~~return~~ over HTTP and if requested it will redirected to HTTPS.		This ensures that no page (image, CSS, JavaScript file, etc.) will be returned over HTTP and if requested it will be redirected to HTTPS.

	You may also want to edit the archive's ssl/securevhost.conf to add the [~~https://wiki.eprints.org/w/~~HTTPS-only_and_HSTS#Add_the_HSTS_header HSTS header].		You may also want to edit the archive's <code>ssl/securevhost.conf</code> to add the [[HTTPS-only_and_HSTS#Add_the_HSTS_header \| HSTS header]].
	$c->{host} = undef;		$c->{host} = undef;
	$c->{port} = 80;		$c->{port} = 80;
Line 30:		Line 32:

	== Issues and Troubleshooting ==		== Issues and Troubleshooting ==
	Inevitably you may still encounter issues even if you use one of the ~~configuration~~ above, so it is advised you test this on a development or pre-production instance of your repository to check you get the behaviour you expect.		Inevitably you may still encounter issues even if you use one of the configurations above, so it is advised you test this on a development or pre-production instance of your repository to check you get the behaviour you expect.

	=== EPrint URI Change ===		=== EPrint URI Change ===
	When an EPrint made live it will acquire a URI in the form:		When an EPrint made live it will acquire a URI in the form

	http://example.eprints.org/eprint/id/1234		<nowiki>http://example.eprints.org/eprint/id/1234</nowiki>

	If you switch over to ''HTTPS Only'' the ~~abive~~ URI will be updated (if you refresh abstracts) to:		If you switch over to [[Simplified_HTTPS_Configuration#HTTPS_Only \| HTTPS Only]] the above URI will be updated (if you refresh abstracts) to

	https://example.eprints.org/eprint/id/1234		<nowiki>https://example.eprints.org/eprint/id/1234</nowiki>

	For most repositories this will not be an issue but if your repository is harvested by a third party application, it may rely on the URI as a unique identifier and if this ~~change~~ it may ~~this~~ all the EPrints are new as none of the URIs are the same as before.		For most repositories this will not be an issue but if your repository is harvested by a third party application, it may rely on the URI as a unique identifier and if this changes it may that all the EPrints are new as none of the URIs are the same as before.

	For third party applications that integrate through the Bazaar (EThoS, PIRUS, Symplectic Repository Tools, etc.) no problems relating to this have been identified. However, if ~~you~~ repository has a bespoke third party application this may be affected and is something you should test beforehand if possible but as soon as you go live with the new configuration otherwise.		For third party applications that integrate through the [http://bazaar.eprints.org Bazaar] (EThoS, PIRUS, Symplectic Repository Tools, etc.) no problems relating to this have been identified. However, if your repository has a bespoke third party application this may be affected and is something you should test beforehand if possible but as soon as you go live with the new configuration otherwise.

	If you need to ensure your EPrint URIs do not change you can add the ~~'''~~uri_url~~'''~~ configuration option at the end of your archive's 10_core.pl configuration as follows:		If you need to ensure your EPrint URIs do not change you can add the <code>uri_url</code> configuration option at the end of your archive's <code>10_core.pl</code> configuration as follows:

	$c->{uri_url} = "http://" . $c->{securehost};		$c->{uri_url} = "http://" . $c->{securehost};

	OAI-PMH (e.g. http://example.eprints.org/cgi/oai2 and https://example.eprints.org/cgi/oai2) provide different relations (http or https) for a publication but the OAI identifier is protocol independent and therefore stays the same. Therefore, third party applications that make use of OAI-PMH should not be affected if they harvest as the protocol specifies.		OAI-PMH (e.g. <nowiki>http://example.eprints.org/cgi/oai2</nowiki> and <nowiki>https://example.eprints.org/cgi/oai2</nowiki>) provide different relations (http or https) for a publication but the OAI identifier is protocol independent and therefore stays the same. Therefore, third party applications that make use of OAI-PMH should not be affected if they harvest as the protocol specifies.

	=== Search Engine Indexing ===		=== Search Engine Indexing ===
	It has been observed in the past that some items may briefly disappear from the Google search index when switching to ''HTTPS Only''. There is no way to guarantee this will not happen. One way to try to mitigate and keep on top of this is to setup a Google Webmaster account and register your repository's hostname. After a couple of days this should get populated with all the pages indexed for your repositories, if there are any missing you can submit these to Google to be re-added.		It has been observed in the past that some items may briefly disappear from the Google search index when switching to [[Simplified_HTTPS_Configuration#HTTPS_Only \| HTTPS Only]]. There is no way to guarantee this will not happen. One way to try to mitigate and keep on top of this is to setup a Google Webmaster account and register your repository's hostname. After a couple of days this should get populated with all the pages indexed for your repositories, if there are any missing you can submit these to Google to be re-added.

	=== IRStats2 Blip in Downloads ===		=== IRStats2 Blip in Downloads ===
	It has also been observed that repositories see a brief drop in downloads (and views) when switching to ''HTTPS Only''. This may be partially due to search engine indexing but is most likely affected by the fact that bots and crawlers (including GoogleBot) will not follow redirects (i.e. from the HTTP URL they already had to the new HTTPS version) and therefore this will not count as a download. IRStats2 has multifarious ways of detecting bots but it is likely a large percentage of downloads will still be due to bots. Therefore, in some ways the blip may actually give a more accurate ~~pictire~~ of the amount of downloads from your repository. However, looking a raw statistic is generally a bad idea, ~~IRStats3~~ is intended to show usage trends and differences more than absolute downloads or views.		It has also been observed that repositories see a brief drop in downloads (and views) when switching to [[Simplified_HTTPS_Configuration#HTTPS_Only \| HTTPS Only]]. This may be partially due to search engine indexing but is most likely affected by the fact that bots and crawlers (including GoogleBot) will not follow redirects (i.e. from the HTTP URL they already had to the new HTTPS version) and therefore this will not count as a download. [https://eprints.github.io/irstats2/ IRStats2] has multifarious ways of detecting bots but it is likely a large percentage of downloads will still be due to bots. Therefore, in some ways the blip may actually give a more accurate picture of the amount of downloads from your repository. However, looking a raw statistic is generally a bad idea, [https://eprints.github.io/irstats2/ IRStats2] is intended to show usage trends and differences more than absolute downloads or views.

Drn@ecs.soton.ac.uk: Added header above config subheaders

2019-05-10T13:54:49Z

Added header above config subheaders

← Older revision		Revision as of 13:54, 10 May 2019
Line 3:		Line 3:
	Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongsot other problems. In EPrints 3.4.1+ the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's '''cfg/cfg.d/10_core.pl''' in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.		Trying to configure EPrints for HTTPS can be difficult and the way the code was previously written, even if you configured HTTPS correctly you could still have issues with mixed content pages, amongsot other problems. In EPrints 3.4.1+ the underlying code has been improved so that you can configure, ''host'', ''port'', ''securehost'', and ''secureport'' in your archive's '''cfg/cfg.d/10_core.pl''' in three different ways to get the behaviour. Other configuration options in this file should not need to be changed.

			== Configurations ==
	'''Make sure you remove or disabled your archive's ''cfg/cfg.d/https.pl'' if it exists as it may override these configuration below. Once you have updated your configuration you must run ''generate_apacheconf'' to regenerate configuration for Apache before restarting the web server.'''		'''Make sure you remove or disabled your archive's ''cfg/cfg.d/https.pl'' if it exists as it may override these configuration below. Once you have updated your configuration you must run ''generate_apacheconf'' to regenerate configuration for Apache before restarting the web server.'''