Radicore Forum: RADICORE Installation Issues

Home » RADICORE » RADICORE Installation Issues » XML/XSL rights issue

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

XML/XSL rights issue [message #47]

Thu, 01 June 2006 14:12

talktozee
Messages: 7
Registered: June 2006

Junior Member

I've recently installed Radicore and have most of the bugs worked out. However, when I try to login (with either the server or client-side options) I receive the following in IE 6.0:

The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.

Access is denied. Error processing resource 'https:///radicore/xsl/std.detail1.xsl'.

In Firefox the code is simply displayed. Is this a rights issue? Have I not set my rights properly in the filesystem? I've tried to set the minimum for security purposes, so I may not have done everything correctly.

You can see my live site here: https://secure.ivado.com/radicore/

Report message to a moderator

Re: XML/XSL rights issue [message #48 is a reply to message #47]

Thu, 01 June 2006 14:32

AJM
Messages: 2382
Registered: April 2006
Location: Surrey, UK

Senior Member

When you say "in Firefox the code is simply displayed" what exactly do you mean? Is the page being rendered into HTML, or is the raw XML being displayed without being transformed by the XSL file?

The resource name causing the error 'https:///radicore/xsl/std.detail1.xsl' looks incomplete to me. It should be something like HTTPS://rocket.secureguards.com/~radicore/demo/xsl/std.detai l1.xsl or even HTTPS://secure.radicore.org/demo/xsl/std.detail1.xsl. What do you have set for $GLOBALS['https_server'] and $GLOBALS['https_server_suffix'] in your CONFIG.INC file?

BTW, the URL you posted, https://secure.ivado.com/radicore/ keeps giving me "page cannot be displayed".

Tony Marston
http://www.tonymarston.net
http://www.radicore.org

Report message to a moderator

Re: XML/XSL rights issue [message #49 is a reply to message #47]

Fri, 02 June 2006 15:39

talktozee
Messages: 7
Registered: June 2006

Junior Member

In Firefox, it renders everything in HTML/text, like so (but in a browser it appears to render all on the same line):

HTTPS://www.ivado.comwww.ivado.com/radicore/style_default.cs s
HTTPS://www.ivado.com/radicore/menu/style_custom.css

LOGIN

Try user_id= 'mgr', password='password'

HTTPS://www.ivado.com/radicore/menu/logon.php
menu0
Logon screen
en

Page
Item
of
FIRST
LAST
PREV
NEXT
show
select all
unselect all
logout
logout (all)
new session
help
page created in
seconds
print
noprint
You are logged in as:
recover password

true

logon
logon
HTTP://www.ivado.com/radicore/menu
HTTP://www.ivado.com/radicore
0.0307

Like you I noticed the path problem, so I did set the $GLOBALS['https_server'] and $GLOBALS['https_server_suffix'] in my CONFIG.INC file to 'www.ivado.com' I'm not sure, however, if this is correct. Even with those entries I get the error.

Also, I checked access to the website from two completely different networks; access seems ok. I will, however, look in the webserver logs (and check my firewall) to see if anything is amiss.

Mik

Report message to a moderator

Re: XML/XSL rights issue [message #50 is a reply to message #49]

Fri, 02 June 2006 16:39

AJM
Messages: 2382
Registered: April 2006
Location: Surrey, UK

Senior Member

If your secure server is HTTPS://www.ivado.com/ and your normal server is HTTP://www.ivado.com/ then you should set your CONFIG.INC as follows:

$GLOBALS['http_server'] = 'www.ivado.com';
$GLOBALS['https_server'] = 'www.ivado.com';
$GLOBALS['https_server_suffix'] = '';

This allows the secure server to be something different like 'secure.ivado.com'

$GLOBALS['https_server_suffix'] is only used if you use a shared server which requires an additional suffix to identify the account. For example, I currently use 'rocket.secureguards.com' as my secure server but this requires a suffix of '/~radicore' to identify the individual account name on that shared host.

Tony Marston
http://www.tonymarston.net
http://www.radicore.org

Report message to a moderator

Re: XML/XSL rights issue [message #51 is a reply to message #47]

Sat, 03 June 2006 07:19

talktozee
Messages: 7
Registered: June 2006

Junior Member

Ok, setting $GLOBALS['http_server'] = ''; and $GLOBALS['https_server'] = 'secure.ivado.com'; fixed the problem (http_server is blank because this server ONLY hosts https://secure.ivado.com).

Which in itself poses another problem, as many links within the application want to navigate to an "http" link, which on this particular server doesn't exist. This server ONLY hosts https://secure.ivado.com

Is there any way to get around this?

Also, I had to drop and recreate the 'audit' table (certain permission errors, etc., very weird). After doing so, however, I cannot login with mgr/password (I'm giving a "Security Violation" error).

Sorry for all of the problems. Having a heck of time getting this to install, but I really think it'll be worth it.

Mik

Report message to a moderator

Re: XML/XSL rights issue [message #52 is a reply to message #51]

Sat, 03 June 2006 07:52

AJM
Messages: 2382
Registered: April 2006
Location: Surrey, UK

Senior Member

It is not standard practice to have an entire website accessed through HTTPS. It is normal to use HTTP for everything except those pages which *must* be secured, in which case HTTPS is used. Radicore follows this convention by assuming everything is HTTP *unless* it has to be HTTPS. A website is either HTTP only or mostly HTTP with some HTTPS.

Instead of trying to install and evaluate this software on a remote server over which you obviously have no control, why don't you do what everyone else does and install it on your own local PC? This would be the best way to develop, test and debug any applications you intend to write.

I do not understand why deleting and recreating the AUDIT database would cause a login error. This is only caused when the user_id/password entered on the screen does not match what is in the USER table. The AUDIT database is not accessed until *after* the logon credentials have been successfully validated.

Tony Marston
http://www.tonymarston.net
http://www.radicore.org

Report message to a moderator

Re: XML/XSL rights issue [message #53 is a reply to message #47]

Sun, 04 June 2006 10:41

talktozee
Messages: 7
Registered: June 2006

Junior Member

Tony,

GREAT idea! Gah, I wish I would have thought of that; I simply went down the path of least resistance and installed it on an existing server.

I have installed WAMP on my desktop machine and am testing Radicore there.

FYI, I do have complete control over the secure.ivado.com server, but I have it setup to NOT allow HTTP requests.

Mik

Report message to a moderator

Re: XML/XSL rights issue [message #54 is a reply to message #53]

Sun, 04 June 2006 11:20

AJM
Messages: 2382
Registered: April 2006
Location: Surrey, UK

Senior Member

talktozee wrote on Sun, 04 June 2006 15:41

FYI, I do have complete control over the secure.ivado.com server, but I have it setup to NOT allow HTTP requests.

Is there any particular reason for that? Sites are usually HTTP only or HTTP with some HTTPS, not HTTPS only.

Radicore assumes HTTP for everything, with HTTPS reserved for selected pages. If a secure page receives a request via HTTP then Radicore will execute header("location: HTTPS://....") to redirect. If a non-secure page receives a request via HTTPS then it is redirected to HTTP.

Tony Marston
http://www.tonymarston.net
http://www.radicore.org

Report message to a moderator

Re: XML/XSL rights issue [message #55 is a reply to message #47]

Sun, 04 June 2006 12:59

talktozee
Messages: 7
Registered: June 2006

Junior Member

This particular server has one particular purpose, and that purpose requires HTTPS-level security for all pages. It doesn't host any websites or process anything other than what it's built for, hence the lack of need on our part for any HTTP requests.

However, I did load an AMP (Apache, MySQL, PHP) package on my Windows laptop and I have Radicore up and running just fine. Much faster and easier, in fact, than on my *nix server.

Report message to a moderator