Here's a little patch to accept the "L1" RIS field == the "File" field when importing data.
It's useful for batch import of many articles with a local copy of the pdfs.
Currently it's reserved to the admin as only the admin can modify the "File" field in refbase.
But I'm wondering what's the exact risk? it seems that ../../.. doesn't work anyway so we can make sure the "File" field cannot help fetching other system files.
diff -Naur -x files refbase-orig/record.php refbase/record.php
--- refbase-orig/record.php 2008-04-22 10:41:56.000000000 +0200
+++ refbase/record.php 2008-04-23 16:29:39.000000000 +0200
@@ -565,6 +565,12 @@
$relatedName = "";
$fileName = "";
+ // if a file location is given by the administrator
+ if ((isset($_REQUEST['file'])) AND (isset($loginEmail)) AND ($loginEmail == $adminLoginEmail))
+ $fileName = encodeHTML($_REQUEST['file']);
+ $fileName = "";
$urlName = encodeHTML($_REQUEST['url']);
> Here's a little patch to accept the "L1" RIS field == the "File" field when importing data.
thanks for the patch! IIRC, refbase does already accept contents of the RIS 'L1' field when importing multiple records at once. However, as you noticed, it currently does not respect the 'L1' field when importing single records (which get loaded into the 'record.php' form.
I haven't tested your patch yet. Note that if relative file paths are given (instead of full file URLs to a remote location), this will probably only work, if you've copied the PDF to the correct location manually. Also, when local file paths/names are accepted from import data, the PDF files currently don't seem to get renamed & filed according to the settings in 'initialize/ini.inc.php' (which they probably should).
> But I'm wondering what's the exact risk? it seems that ../../..
> doesn't work anyway so we can make sure the "File" field cannot
> help fetching other system files.
I'd need to further test this. Also, it might depend on the specific server setup...