No page image loading

[csidirop]

Description

Using latest presentation and DFG-Viewer code lead to GET error 404 eID not registered (see error message below), so that the image cannot be loaded.

I tracked this bug down to following commit: 2578e7a from 27 Oct. 22. This commit contained changes in PageViewPlugin.php and setup.typoscript which have changed the behavior of the get request.

For the moment not using the internal proxy fixes the issue.

Reproduction

Steps to reproduce the behaviour:

1. Install DFG-Viewer (via git or via composer)
2. Go to the dlf directory
3. Checkout the 4.x branch (or master)
4. Load any page

Expected Behavior

The page image is shown.

Screenshots and Examples

The full error message:

XHRGEThttp://localhost/viewer?eID=tx_dlf_pageview_proxy&uHash=1a8f61cbdabff7dababfbf0fb342afe6977dfc8e&url=https://digi.bib.uni-mannheim.de/fileadmin/vl/ubmaosi/59088/max/59088_0008.jpg&cHash=28049111f2f2de01bae17e947a07503c
[HTTP/1.1 404 eID not registered 15ms]

	
GET
	http://localhost/viewer?eID=tx_dlf_pageview_proxy&uHash=1a8f61cbdabff7dababfbf0fb342afe6977dfc8e&url=https://digi.bib.uni-mannheim.de/fileadmin/vl/ubmaosi/59088/max/59088_0008.jpg&cHash=28049111f2f2de01bae17e947a07503c
Status
404
eID not registered
VersionHTTP/1.1
Übertragen277 B (0 B Größe)
Referrer Policystrict-origin-when-cross-origin

    	
    Connection
    	Keep-Alive
    Content-Length
    	0
    Content-Type
    	text/html; charset=UTF-8
    Date
    	Wed, 08 Feb 2023 09:22:06 GMT
    Keep-Alive
    	timeout=5, max=98
    Server
    	Apache/2.4.54 (Debian)
    X-Content-Type-Options
    	nosniff
    X-UA-Compatible
    	IE=edge
    	
    Accept
    	*/*
    Accept-Encoding
    	gzip, deflate, br
    Accept-Language
    	de,en-US;q=0.7,en;q=0.3
    Connection
    	keep-alive
    Cookie
    	Typo3InstallTool=g25tugvmdm2fm88cefkj0qpmfq; tx-dlf-ocrEngines=%7B%0A%20%20%20%20%22ocrEngines%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22name%22%3A%20%22Tesseract%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22de%22%3A%20%22Tesseract%20%28frak2021_1.069%29%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22en%22%3A%20%22Tesseract%20%28frak2021_1.069%29%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22class%22%3A%20%22tesseract%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%2…%20%20%20%20%20%20%20%20%22class%22%3A%20%22kraken%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22data%22%3A%20%22kraken-german_handwriting_best%22%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%5D%0A%7D; tx-dlf-pageview-zoomLevel=1.5230677770956063; tx-dlf-pageview-centerLon=998.6932529588169; tx-dlf-pageview-centerLat=-1040.792446416572; tx-dlf-ocrEngine=kraken-digitue_best; fe_typo_user=540dcee7a4d5569782e70dac13528e85; tx-dlf-pageview-fulltext-select=enabled; be_typo_user=be324cc477dd43561d4ae980774f29f6
    Host
    	localhost
    Referer
    	http://localhost/viewer?tx_dlf%5Bid%5D=https%3A%2F%2Fdigi.bib.uni-mannheim.de%2Ffileadmin%2Fvl%2Fubmaosi%2F59088%2F59088.xml&tx_dlf%5Bpage%5D=8&cHash=59e53d23765a566daa1b66ee56449d83
    Sec-Fetch-Dest
    	empty
    Sec-Fetch-Mode
    	cors
    Sec-Fetch-Site
    	same-origin
    User-Agent
    	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0

Environment

• OS version: Debian
• RDBMS version: Maria DB (MySQL 5.5.5-10.9.3-MariaDB-1:10.9.3+maria~ubu2204 )
• Apache Solr version: -
• TYPO3 version: 10.4.35
• PHP version: 7.4.33

Additional Context

[csidirop]

An other way to reproduce this, is to use our docker images:

1. Clone repo: git clone https://github.com/UB-Mannheim/kitodo-presentation-docker
2. Change dir: cd kitodo-presentation-docker
3. Change branch: git checkout dfg-viewer-dev
4. Start docker container: docker compose up
5. Wait till everything is up
6. (you may need to re-save the page configuration: BE -> Site Management -> Site: edit and save)
7. open: localhost and use any of the examples or use your own METS file, e.g.: http://localhost/viewer?tx_dlf[id]=https%3A%2F%2Fdigi.bib.uni-mannheim.de%2Ffileadmin%2Fvl%2Fubmaosi%2F59088%2F59088.xml

[sebastian-meyer]

The problem seems to be the following:

1. Commit 2578e7a introduced a change to setup.typoscript enabling the use of the internal image proxy by default.
2. The image proxy uses the eID script PageViewProxy.php to access external files, which is registered in ext_localconf.php.
3. BUT: Registration of the eID script only happens when the extension configuration option enableInternalProxy is set in ext_conf_template.txt, which it is not by default.

So we have a mismatch of default configuration requiring the use of the internal proxy in the PageView plugin, but not enabling it in the first place. I suggest reverting the change to setup.typoscript and thus restoring the old behavior. Furthermore the image proxy should only be used if necessary anyway while the default should be to rely on CORS headers.

What do you think, @csidirop and @beatrycze-volk?

[beatrycze-volk]

If after that proxy for 3D models works, than I'm fine with your solution :)

[sebastian-meyer]

If after that proxy for 3D models works, than I'm fine with your solution :)

We would have to rework this a little bit: Currently there are two different configuration options effectively meaning the same thing: enableInternalProxy is part of the (global) extension configuration while the newly introduced plugin.tx_dlf.settings.useInternalProxy is a typoscript setting. Their differences are only marginal: the first option globally enables or disabled the image proxy while the second options makes its use mandatory.
Maybe we should combine both options into one? We could expend on enableInternalProxy like this:

Instead of being a boolean switch, enableInternalProxy should be of type options (see Extension Configuration)

• If enableInternalProxy = off the behavior would be the same like currently enableInternalProxy = 0: the use of the proxy script is completely turned off irrespective of any typoscript settings for individual plugins. This should also be the default.
• If enableInternalProxy = always the behavior would be the same like currently enableInternalProxy = 1 AND plugin.tx_dlf.settings.useInternalProxy = 1. This would be the preferred setting for the DFG-Viewer 3D (but not the default for Kitodo.Presentation).
• If enableInternalProxy = on the behavior would be the same like currently enableInternalProxy = 1 AND plugin.tx_dlf.settings.useInternalProxy = 0.

But I am not sure if I understand the meaning of plugin.tx_dlf.settings.useInternalProxy correctly. Maybe it's just a duplicate of enableInternalProxy and we should get rid of it?

[csidirop]

What do you think, @csidirop and @beatrycze-volk?

Yes I think we need a consistent way of doing it. I think the approach to leave it as it was by default and activate it as needed is good. But to be honest I haven't understood exactly what the internal image proxy does and what it's for.
I don't have any 3D models (nor do I know how) that I could test to see if it still works. @beatrycze-volk would have to test that.

[beatrycze-volk]

But I am not sure if I understand the meaning of plugin.tx_dlf.settings.useInternalProxy correctly. Maybe it's just a duplicate of enableInternalProxy and we should get rid of it?

I think we got here to some deeper misunderstanding. useInternalProxy is not newly introduced. In general, we have already in code useInternalProxy (PageView.xml) e.g.

<settings.useInternalProxy>
    <TCEforms>
         <exclude>1</exclude>
           <label>LLL:EXT:dlf/Resources/Private/Language/locallang_be.xlf:plugins.pageview.flexform.useInternalProxy</label>
           <config>
                  <type>check</type>
                 <default>0</default>
           </config>
       </TCEforms>
 </settings.useInternalProxy>

Also in places in which we are using proxy we are querying for $this->settings['useInternalProxy']. My idea by introducing it to the typo setup was to avoid double setting it in the both of plugins. (I didn't yet remove this setting from those plugins FlexForms). While I was doing it, I have missed existence of enableInternalProxy. I see now, that enableInternalProxy is used for activating eID script as @sebastian-meyer has mentioned.

We need to definitely consolidate those two settings into one. For now probably reversing of adding it to the global typo setup should solve the problem.

[csidirop]

How should we proceed here?

[sebastian-meyer]

I am currently working on simplifying the 3D support and in turn reverting the changes regarding the internal proxy. It will take a few more weeks due to vacations, but this should fix this issue.

[csidirop]

Okay thanks.

[csidirop]

It seams like with the version 4.x from 21 Jul 23 (38b64ca) the image is shown again.

Is this fixed or a workaround / temporally solution or even just a coincidence?

[csidirop]

Close the issue because it is probably fixed, even if it is not clear why.