Production server: RUcore link is broken on showfed screen

Project:RUcore dlr/EDIT
Version:7.0
Component:Code
Category:bug report
Priority:normal
Assigned:dhoover
Status:closed
Description

The link to RUcore on showfed produces "403 Forbidden -- You don't have permission to access / on this server". error message.

Clicking on the RUcore Image above the link works OK.

Comments

#1

Title:RUcore link is broken on showfed screen» Production server: RUcore link is broken on showfed screen

#2

Not sure this is mine. The link appears to come from this source:
require_once("$filebase/rucore/incs/bread_header.inc");
and it produces:
<div class="body_breadcrumb">
<ul>
<li><span class="bread_raquo">»</span><a href="/">RU<strong>core</strong></a></li>
<li><span class="bread_raquo">»</span>RU<strong>core</strong> Resource Object</li>
</ul>
</div>
<!--end breadcrumbs-->

the "/" tries to link to the mss3.libraries.rutgers.edu directory and thus fails with the 403 since directory listings are forbidden in the apache config.

#3

The problem is two fold.

The use of require_once("$filebase/rucore/incs/bread_header.inc");
translates to /home/httpd/html/rucore/...
but the servername being used is inherited by the URL that the
handle (and hence showfed takes you to)

In my test the handle went to rep-prod.libraries.rutgers.edu (which
was supposed to be changed to mss3.libraries.rutgers.edu) I thought
this was handled shortly after the release on the new servers, so it
could be that my record was an early one. So the rucore link went
to rep-prod.libraries.rutgers.edu when it should go to
rucore.libraries.rutgers.edu

I think the fix would be to use rucorebase from /mellon/includes/incs
in the bread_header.inc file which should work on all servers, it would
just need to be tested.

/mellon/includes/incs from all 3 servers:

dhoover@rep-devel:~> grep rucorebase /mellon/includes/incs
$rucorebase = "$serverbase/rucore";
dhoover@rep-devel:~> grep "^\$serverbase" /mellon/includes/incs
$serverbase = "rep-test.libraries.rutgers.edu";

dhoover@rep-staging:~> grep rucorebase /mellon/includes/incs
$rucorebase = "rep-staging.libraries.rutgers.edu/rucore";

dhoover@rep-prod:~> grep rucorebase /mellon/includes/incs
$rucorebase = "rucore.libraries.rutgers.edu";
$showfedlogo = "http://$rucorebase/img/frontpg_title.gif";

#4

The bread_header.inc was created for the RUcore site. It shouldn't need to use or call any external include files to use other variables.

The real problem is the way the include file is being used. $home is a variable used and inherited by the include. showfed.php is using the wrong value in the $home variable, it needs to redefine it before calling the include. $home was designed for use on the RUcore website, and not meant to be used in other sub-domains.

#5

I'm not using variables from any other include files for these links - only what I get from bread_header.inc.

#6

bread_header.inc does NOT set any variables, it only uses variables it has inherited from the script it is being included in.

On line 120 showfed.php DOES "get" the variables used by the bread_header.inc script.

120 : require_once("$filebase/rucore/incs/globals.inc");

and then it uses them when being included on line 150.

150 : require_once("$filebase/rucore/incs/bread_header.inc");

The include file called on line 120 is designed and configured to be used from rucore.libraries.rutgers.edu, not mss3.libraries.rutgers.edu. If you are going to continue to use that include file, then change the $home variable that is set by the call at line 120 before the include on line 150.

#7

Status:active» test

OK. For the time being, this will work perhaps.
120 require_once("$filebase/rucore/incs/globals.inc");
121 if ($serverbase == "mss3.libraries.rutgers.edu") {
122 $home = "/rucore/";
123 }
I don't know how we can test it without moving the code out to mss3 though since this problem only occurs there.

#8

That is not going to work. You are going to then redirect users to the following URL.

<a href="http://mss3.libraries.rutgers.edu/rucore/" title="http://mss3.libraries.rutgers.edu/rucore/">http://mss3.libraries.rutgers.edu/rucore/</a>

Two problems, one is the use of mss3.libraries in the URL and the other is the site is meant to be served from rucore.libraries.

#9

Then how about this?
120 require_once("$filebase/rucore/incs/globals.inc");
121 if ($serverbase == "mss3.libraries.rutgers.edu") {
122 $home = "rucore.libraries.rutgers.edu/";
123 }

#10

Yes, the full address should work.

$home = "http://rucore.libraries.rutgers.edu";

Do you call any other web site includes after making that variable change?

#11

I do a couple:
127 require_once("$filebase/rucore/search/lib/config.php");
147 require_once("$filebase/rucore/incs/left_nav.inc");
153 require_once("$filebase/rucore/incs/bread_header.inc");
171 print "<script type=\"text/javascript\" src=\"http://$rucorebase/js/lib/simple.pop.500.js\"></script> \n";
172 print "<script type=\"text/javascript\" src=\"http://$rucorebase/js/lib/switch.display.js\"></script>\n";
173 print "<link href=\"http://$rucorebase/css/search/results.css\" rel=\"stylesheet\" type=\"text/css\" />\n";
Various beginning with:
214 $ndstreams = file("http://$rucorebase/api/get/$pid/fulllist/");
267 $thumblink = "http://$rucorebase/img/search/";
Should these later $rucorebase calls be reset to the $home perhaps?

#12

I do not know how those variables are being used, so i cannot say for certain. In general referencing "rucore.libraries" as much as possible over "mss3.libraries" is preferred.

#13

These are mostly for file includes from the rucore subdirectory of $filebase or some special sockets to $serverbase/rucore. I think the only thing that isn't working across the servers is the $home pulled from globals.inc.

#14

The use of the $home variable is to reset the directory path to either "/" or "/rucore"
depending on which type of Apache configuration is in use.
Ie servername/{default document root} or servername/rucore
mss3.libraries.rutgers.edu/rucore or rucore.libraries.rutgers.edu

It is not meant as a way to set a servername as the fixes that are being outlined
attempt to do.

The problem is that the redirection of the handle that goes to showfed directs
people to mss3.libraries.rutgers.edu/dlr/EDIT/... which then becomes the
servername that is being handed off to the breadcrumb link.

Since it appears that showfed only provides a 2 level breadcrumb (which will never
be greater than that) and that only the RUcore one is a link and considering
that everything else on the page appears ok, I am not sure why the use of
the $rucorebase variable in /mellon/includes/incs as outlined in comment
#3 above won't serve the purpose? Is calling the breadcrumb code really necessary?

#15

Dave,

bread_header.inc is a RUcore website include, not a dlr/EDIT include. $home is a long standing and heavily used variable for the RUcore site. Replacing the variable used in a website include file to use a dlr/EDIT variable wouldn't be sensible in my opinion.

The reason to keep the bread crumb would be for site continuity. It establishes a navigation behavior users can depend on.

#16

I know that, so to not muddle the waters I will remove myself from the
discussion and await the fix.

#17

Nothing should be pointing to dlr/EDIT from showfed. The outlying wrapper now gets its data from the rucore includes. It is just a matter of tweaking the breadcrumb link properly so that it won't be "/" on the production server.

#18

Status:test» active

#19

Version:6.1.2» 7.0

#20

Status:active» test

This should be tested on production by copying down the showfed.php file from rep-devel (under a different name, say, fooshowfed.php) and changing the urls for some showfed displays to see if the new $home value is picked up.

#21

The new value of $home has been picked up and the link is still
broken. You can try the "fooshowfed.php" test yourself to see
what I mean.

#22

Thanks Dave. I think we're making some progress. The new value is being added "relatively" after the base URL now rather than being left blank. I've prepended "http://" which should force the value to be taken as a literal URL. Would you mind testing again?

#23

Assigned to:triggs» dhoover

#24

Status:test» closed

It is working OK now.

Back to top