DNB Plugin problems in OJS 3.4.0.8

Hi,

we want to start delivering data to the DNB via DNB plugin after upgrade to OJS 3.4.0.8 was successfull. We received hotfolder credentials and when starting the test delivery, several problems occured.

  1. When opting in for the experimental features and after closing and restarting the plugin, I receive a blank white page. I can go back in the browser to the tool list, but when clicking the DNB plugin again the page is blank again. Apache error log shows

Got error 'PHP message: PHP Warning:  file_put_contents(): open_basedir restriction in effect. File(/var/www/html/files/dnb/response_1439-040X-issn.xml) is not within the allowed path(s): (/var/www/disabled/:/var/www/auto_prepend/:/usr/share/php/:/tmp/:/dev/urandom:/var/www/ojs.openagrar.de/:/bin/tar:/usr/bin/perl:/bin/egrep:/bin/gzip) in /var/www/ojs.openagrar.de/plugins/importexport/dnb/classes/DNBCatalogInfoProvider.php on line 263; PHP message: PHP Warning:  file_put_contents(/var/www/html/files/dnb/response_1439-040X-issn.xml): Failed to open stream: Operation not permitted in .........

Am I right to assume that our server settings are too strict and have to be adjusted? What would I have to tell my server admin to adjust?
Unfortunately, I cannot de-select the experimental features at this point since the page is blank.

  1. In a second journal in this same multi-journal installation, I entered the DNB credentials and DID NOT select the experimental features. No blank page occures, the plugin settings and article deposit list are available. However, export isn’t working, nor is the test deposition of data. The same error message in OJS backend occurs for both actions:

There is no error in the apache error log.
I would be grateful for some ideas and tips on how to fix this. Maybe @ronste1 can help?

We use OJS 3.4.0.8 that was recently upgraded from OJS 3.3.0.8 (started out as 2.2.3.0 in 2009 and went through several upgrades since)
PHP version 8.3.16

Hi @heike_riegler,

I’ll let someone else comment on the DNB plugin – but it looks like you may have installed OJS unsafely! The files_dir (in config.inc.php) should not be placed somewhere web-accessible, as noted in the installation form, configuration file, and documentation. You should move this immediately outside of the web root and check your server for signs of attack.

Regards,
Alec Smecher
Public Knowledge Project Team

Dear @heike_riegler ,

the DNB already informed me about the issue. And, as you already guessed, the warning/error messages you provided both indeed point to a server configuration issue.

For the DNB-Plugin to work correctly write access to the OJS files dir is required to store temporary information. Actually this is true for many features of OJS. If write access to your files dir is prohibited by your php.ini open_basedir setting (as is suggested by the warning message you provided) I wonder how you at all could upload files to OJS. But maybe I am missing something about your configuration.

Once permissions to the OJS files dir are set corretly I would expect the DNB-Plugin to work. If this should not be the case please feel free to contact me again.

Best wishes,
Ronald

1 Like

Well, the plugin tries to write to /var/www/html/files which is not the home of the OJS installation. The DocumentRoot and “home” is /var/www/ojs.openagrar.de.

The value of the files_dir variable is also not files.

Where does /var/www/html come from? Feels somehow like a default/fallback?

Ok, I got the point and indeed this originates from the experimental feature. I fixed it in the repo. Can you try this new (I didn’t change the version number) package: https://github.com/ojsde/dnb/releases/tag/v1.6.0

This explains the first issue from above. Regarding the second issue: Can you verify the permissions of the files/dnb folder? Your web server should have write permissions.

Looking at your paths allowed by open_basedir:

the allowed path(s): (/var/www/disabled/:/var/www/auto_prepend/:/usr/share/php/:/tmp/:/dev/urandom:/var/www/ojs.openagrar.de/:/bin/tar:/usr/bin/perl:/bin/egrep:/bin/gzip)

I can’t identify a path that could be related to the files folder.

This topic was automatically closed after 12 days. New replies are no longer allowed.

I have some updates.

We tested the linked version but it still fails at the SFTP upload because the paths are still wrong:

File(/var/www/html/files/dnb/response_1439-040X-issn.xml) is not within the allowed path(s) which is perfectly expected, because - again - our OJS does NOT live in /var/www/html.

The DocumentRoot as well as the files_dir parameter are ignored again?

The plugin should have determined the paths as /var/www/html/ojs.domain.tld/volltexte/dnb/response_1439-040X-issn.xml:

  • ojs.ourdomain.tld ist the Apache vHost DocumentRoot
  • volltexte is our configured files_dir

Ah. There is some debug code inside the release…

https://github.com/ojsde/dnb/blob/259710f27a11d2c399ab7b911d58a80ab78fbad9/classes/DNBCatalogInfoProvider.php#L262

I removed this from our version and retest

We tested without the debug code and now we recieve:

file_get_contents(): Peer certificate CN='d-nb.info' did not match expected CN='services.dnb.de' in /var/www/ojs.domain.tld/plugins/importexport/dnb/classes/DNBCatalogInfoProvider.php on line 259

I dont know why. My SSL-test did not showed any certificate errors. Maybe a file_get_contents thing? We are sitting behind an HTTP-Proxy.

EDIT: d-nb.info also redirects to https://portal.dnb.de/, maybe outdated URL?

Hi @Commifreak ,

thanks for the update. Before I go into the details I like to make sure we both are on the same page regarding the issues described in this thread.

In the original post two different issues were described: The first one related to the experimental feature of the ISSN lookup. The second related to the SFTP upload, a core functionality of the plugin. Both issues are completely independent of each other, conceptually and with respect to the code.

The fix coming with the package I linked above (and with the updated branch ojs-stable-3_4_0) will only handle the first issue related to the experimental feature. With respect to the second issue I currently don’t have a clue. I don’t have enough information about your system to guess what might be the reason.

Coming to your update. You write:

Blockquote
“… it still fails at the SFTP upload because the paths are still wrong:
File(/var/www/html/files/dnb/response_1439-040X-issn.xml) …”

The path you provide here is related to the experimental feature and and has nothing to do with the SFTP upload. It is generated in the file “DNBCatalogInfoProvider.php”:

https://github.com/ojsde/dnb/blob/ff766a232c0897a10e3c94db21e16340be96ae72/classes/DNBCatalogInfoProvider.php#L265

file_put_contents(
					Config::getVar('files', 'files_dir').'/dnb/response_'.$debugFileId.'.xml',$response
				);

As you can see, now in the updated version, the path is clearly taken from the config.inc.php file. If you still get this path with the updated code I have to conclude that it comes from your config file.

However, this code is not in any way related to the “SFTP upload”, i.e. the second issue.

The SFTP upload is handled in “DNBExportPlugin.php”:

https://github.com/ojsde/dnb/blob/ff766a232c0897a10e3c94db21e16340be96ae72/DNBExportPlugin.php#L658

$filename = Config::getVar('files', 'files_dir') . '/' .  $filename;

The error is thrown in line 667 in case $filename doesn’t exists. Again, and this is original code, the path is and alwas was taken from the config file.

The folder that should contain this file is created in “DNBExportPlugin.php”:

https://github.com/ojsde/dnb/blob/ff766a232c0897a10e3c94db21e16340be96ae72/DNBExportPlugin.php#L1107

Using the OJS file service:

if (!Services::get('file')->fs->has($exportPath)) {
			Services::get('file')->fs->createDirectory($exportPath);
}

The OJS file service also uses the config files setting internally.

Bottom line is: In the code I cannot see any more references to “/var/www/html”. I have no idea where it should come from.

There are things we can check:

  1. Does your files folder contain a folder “dnb”?
  2. If so, does it contain any files?

The issue from Post 1 and Post 7 are the same issue: The debug code. This is being fixed by commenting the lines.

The errors shown are bundled with the error message “SFTP upload failed” from the frontend.
The Issue from Post 9 (certificate) is the current one we are facing.
The dnb folder inside our files_dir exists but its empty.

EDIT: I adjusted the debug path to /tmp/ and this creates some files:

grafik

This is exactly the line that I fixed in the updated branch and in the package linked above.

So is it now working as expected?

No, see latest post.

The SSL certificate error you describe is also related to the experimental feature. Please disable the experimental feature to query the DNB catalog. If you can’t do it via the backend go to the database:

MariaDB [ojs]> select * from plugin_settings where setting_name like 'dnbCatalog';
+-------------------+-----------------+------------+--------------+---------------+--------------+
| plugin_setting_id | plugin_name     | context_id | setting_name | setting_value | setting_type |
+-------------------+-----------------+------------+--------------+---------------+--------------+
|                47 | dnbexportplugin |          1 | dnbCatalog   | 1             | bool         |
+-------------------+-----------------+------------+--------------+---------------+--------------+
1 row in set (0.000 sec)

Set setting_value for dnbCatalog to 0

Does the plugin work if you diable the catalog info feature?

No, the 1.6.0 tag (link from above) does not include this fix.

Hi. We have now disabled the dnbCatalog setting (it was active for the first context):

grafik

Unfortunately, it still does not work:

file_get_contents(): Peer certificate CN=`d-nb.info' did not match expected CN=`services.dnb.de' in /var/www/ojs.domain.tld/plugins/importexport/dnb/classes/DNBCatalogInfoProvider.php on line 259

and:

file_get_contents(https://d-nb.info/XXXXXX/about/marcxml): Failed to open stream: Cannot connect to HTTPS server through proxy in /var/www/ojs.domain.tld/plugins/importexport/dnb/classes/DNBCatalogInfoProvider.php on line 259

The latter is weird, as we have correctly set the proxy. And OJS is able to connect to the internet using this proxy, so not sure what the issue is here.

Our OJS proxy is set like:

;;;;;;;;;;;;;;;;;;
; Proxy Settings ;
;;;;;;;;;;;;;;;;;;

[proxy]

; The HTTP proxy configuration to use
http_proxy = "http://1.2.3.4:8000"
https_proxy = "http://1.2.3.4:8000"

Are you sure it is the correct context?

According to the code the class “DNBCatalogInfoProvider” should not be loaded at all if this setting is zero:

https://github.com/ojsde/dnb/blob/ff766a232c0897a10e3c94db21e16340be96ae72/DNBExportPlugin.php#L399

// query dnb catalog
if ($this->getSetting($this->_currentContextId, 'dnbCatalog')) {
$dbnCatalogInfoProvider = new classes\DNBCatalogInfoProvider();
$dnbCatalogInfo = $dbnCatalogInfoProvider->getCatalogInfo($context, Config::getVar('files', 'files_dir').'/'.$this->getPluginSettingsPrefix());
$templateMgr->assign('dnbCatalogInfo', $dnbCatalogInfo);
}

I don’t see how you could get the error message from this class. Are there other context for which the feature is switch on? If so please switch it of for all.

Hi.

Yes, we have this part of code as well (since I used the packages from tag 1.6.0). But, as said: The dnbCatalog feature is off.

Frashly queried from the SQL-Server:

There is no other context/journal with activated DNB. Not sure what to check. We cleared the cache and I let it try again.

Did you take the " dnb-1.6.0.tar.gz " file from Mar 7 or did you take the " Source code (tar.gz) " from Feb 28, 2024?

I verified the code and the newer version from Mar 7 does contains the fix.

Anyway, the point is the plugin has been tested extensively and is known to work with the experimental feature disabled. It is in use on various other journals without problems (although some proxy configuartions might need special attention). If you disabled the experimental feature, does the plugin work?