This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » Developer » rogue siteaccess name 'administrator'...
expandshrink

rogue siteaccess name 'administrator' in cached templates

rogue siteaccess name 'administrator' in cached templates

Friday 21 September 2012 9:27:17 am - 9 replies

Dear All, here is an odd one I need help with.

  • A website running eZ Publish ended up looking like it was missing stylesheets, broken links, etc.
  • Upon inspection, it appears that ezurl and ezdesign generated urls have ended up using the prefix '/administrator/' as the siteaccess name. This gets cached and the whole site breaks.
  • It breaks - because there is no siteaccess with that name and all requests end up with 'module not found' - which is correct.

But Wait! There's more:

This happened again on another server with another verison of eZ Publish - the exact same way.

 

Research:

It *appears* that the first entry was a random request for http://my.domain/administrator and somehow from that point, eZPublish gets as far as writing some cached blocks (like header info) using the /administrator as a  siteaccess

No, there is no entry for 'administrator' in any ini file anywhere

 

Any Ideas?

-David

Friday 21 September 2012 2:58:24 pm

Hello,

A few things comes to mind :

In site.ini.append.php of all used siteaccess, verify

[SiteSettings]
SiteURL=

Make sure that the var/ is writeable for the webserver (chown then chmod) and then empty the cache.

Also check your RewriteRules in .htaccess and/or VirtualHost.

Regards,

Monday 24 September 2012 3:48:18 pm

Hi

1. ezdesign() is not supposed to add any siteaccess in the URL. Because design elements are meant to be accessed directly through Apache and not PHP, I don't understand why your website has started to go wrong suddenly ("designly" speaking)

  • when you try to access the design elements directly, do you get an Apache 404 or is it a response sent by eZ Publish (see your HTTP headers) ?

2. point #1 is not really true for packed JS and CSS if you use eZJScore.

  • verify that the needed JS and CSS are well generated in var/.../public/...

3. regarding URLs generation, as suggested by Guillaume, you should check your site.ini, particularly the [SiteSettings] section and the SiteURL, MatchOrder, and other access related settings

I know that you are an experience developer and are used to use eZ Publish, so I'm pretty sure that you have already tried that... If it does not help you, this could help someone else, at least...

And I also know that this kind of crazy things happens sometime, so keep faith and keep us updated ! happy.gif Emoticon

Cheers,

Arnaud

Monday 24 September 2012 10:53:52 pm

I don't want to jump the gun but David and I have been discussing this and it looks like it's a bug... (but we haven't been able to figure out where it's coming from yet) - but, try it.  got to http://<your-site>/foobar/index.php right after clearing cache - and then do a grep -R foobar var/*/cache var/cache - you'll end up getting something back... which shouldn't (?) happen.

Tuesday 25 September 2012 9:52:03 am

@Steven the url you give is to be used for a vhost-configured site, right?

Tuesday 25 September 2012 10:02:22 am

Yup.. strange:

 

In my case across multiple installs:

  • http://yourdomain.com/index.php will be broken and you will see "/anything/css/whatever"
    • In other-words, the '/anything' makes it into the cache
  • Then I think my specific installation and settings for a default siteaccess then mean that the default siteaccess is broken the same way:

So:

  • maybe some bad setting related to cache and default siteaccess
  • maybe something funny about the rewrite rules

In all cases, strange to have paths generated for content that does not exist.

 

-David

Tuesday 25 September 2012 10:21:47 am

Quote from Arnaud Lafon :

Hi

1. ezdesign() is not supposed to add any siteaccess in the URL. Because design elements are meant to be accessed directly through Apache and not PHP, I don't understand why your website has started to go wrong suddenly ("designly" speaking)

  • when you try to access the design elements directly, do you get an Apache 404 or is it a response sent by eZ Publish (see your HTTP headers) ?

2. point #1 is not really true for packed JS and CSS if you use eZJScore.

  • verify that the needed JS and CSS are well generated in var/.../public/...

3. regarding URLs generation, as suggested by Guillaume, you should check your site.ini, particularly the [SiteSettings] section and the SiteURL, MatchOrder, and other access related settings

I know that you are an experience developer and are used to use eZ Publish, so I'm pretty sure that you have already tried that... If it does not help you, this could help someone else, at least...

And I also know that this kind of crazy things happens sometime, so keep faith and keep us updated ! happy.gif Emoticon

Cheers,

Arnaud

Guillaume, Arnaud Lafon,

Thanks for the suggestions.  Yes, I'm an experienced developer. That's the bad part - I expect that I am overlooking the most obvious thing that will make me hit my head against the wall and go 'Duh!'  I'm convinced that its a goofy combination of default site siteaccess and apache rewrite rules combined to make a funny combination.  It's clear that it happens because a direct hit on index.php - which is probably something I can fix in rewrite rules.

As for what happens when you go to the resource directly:

 

Steven E. Bailey,

Yeah - a bit odd - index.php is generating urls in the cache for something that does not exist - but maybe thats right?!?.

Gaetano Giunta

Yes - my samples are vhost configured (read above - most likely my head in the sky missing the obvious)

 

Thanks everyone - then I find the cause, I'll post back.  In the meantime - google sucks - it was also indexing with the bad content when I was trying to figure out the cause happy.gif Emoticon

Tuesday 25 September 2012 2:54:58 pm

Have you tried to reproduce this behavior on a fresh installation of eZ Publish ? If yes and if you were able to reproduce it, then you should fill an issue on your customer portal if running an Enterprise Edition. For me, it sounds like a bug since you have experienced the same issue on another site and another server.

In the meantime, you should force Apache to send a 404 when the URL contains something you don't want, so that bad contents do not get indexed in Google.

Tuesday 25 September 2012 7:35:26 pm

The ezsiteaccess class starts off assuming you are on the default siteaccess 

     $access = array( 'name' => $ini->variable( 'SiteSettings', 'DefaultAccess' ),                         
                                  'type' => eZSiteAccess::TYPE_DEFAULT,
                                  'uri_part' => array() );

before it does any further processing. So if for some reason you enter a url that indicates a non-existant site access, ez thinks current siteaccess = default.

When template compilation occurs, current siteaccess is used to set the cache file path.

...this leads to the problem you are experiencing.

This probably counts as an ez bug - though you could add some rewrite rules to strip out anything before the index.php that does not match a legit siteaccess.

Wednesday 26 September 2012 10:44:49 am

Quote from David Broadfoot :

The ezsiteaccess class starts off assuming you are on the default siteaccess 

     $access = array( 'name' => $ini->variable( 'SiteSettings', 'DefaultAccess' ),                         
                                  'type' => eZSiteAccess::TYPE_DEFAULT,
                                  'uri_part' => array() );

before it does any further processing. So if for some reason you enter a url that indicates a non-existant site access, ez thinks current siteaccess = default.

When template compilation occurs, current siteaccess is used to set the cache file path.

...this leads to the problem you are experiencing.

This probably counts as an ez bug - though you could add some rewrite rules to strip out anything before the index.php that does not match a legit siteaccess.

Thanks for the analysis of ezsiteaccess. Odd that it has never been noticed before now sad.gif Emoticon Makes me think Its still a mistake on my part.

Yes, as far as I can see, I should be able to strip out any url call to index.php with a rule like:

.?/index.php index.php #index.php after a slash that has any other content before it

This is because our valid urls never include index.php for our instalations.

Gonna try it now happy.gif Emoticon

 

Thanks to everyone for the feedback!  I'll repost back once more to confirm of the quick-fix works

 

-david

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from