Hi Will,

The multi-site "URL shortening" is a SEO feature. In production, it's "nice" to 
have your site-root directly accessibly under the domain, without a 
conceptually unnecessary path-element cluttering the URL. At the same time it 
is very convenient for development that you can still access the site by 
addressing it by IP (or generic name) and the site-name.

In our experience it works well. We haven't observed the URL-Security problem 
you mention. In our production environment we have one URL-Rule set up to block 
/A/B, and this is sufficient to catch calls both to "192.168.1.1/A/B" as well 
as "www.domain.com/B<http://www.domain.com/B>". We're on magnolia EE 4.4.8.

Things get more complicated with multi-language and protecting DMS access as 
well. In this case there are more parts of the URL to consider:
For multi-language, it's the language prefixes like /en/A/B, /de/A/B etc...
For DMS, you have to keep in mind that one site can access another site's DMS 
content with URLs like 
www.domain.com/othersite/dms/path/to/content<http://www.domain.com/othersite/dms/path/to/content>.
The same works for website content too - you can see content from one site "in 
another site" by creating URLs like 
www.domain.com/othersite/<http://www.domain.com/othersite/>..., although 
usually the rendering is messed up because the themes don't match.

Another thing to keep in mind are "static dms" accesses - you can get any DMS 
node by UUID by calling something like 
www.domain.com/dms-static/cafebabe-babe-cafe-beef-beefcafe/myfile.jpg<http://www.domain.com/dms-static/cafebabe-babe-cafe-beef-beefcafe/myfile.jpg>
 - might be best to disable this on the public nodes if you don't need it (see 
config --> /server/filters/servlets/DMSDownloadServlet/mappings).

And another thing to consider is URLs of the form /.imaging/... which will 
allow you to get at any image in DMS (maybe not in original size, but at least 
via some existing variation).

Our solution to all this: we use Apache in front of tomcat to filter out the 
accesses we don't like, but it's not the perfect solution, as we need O(n^2) 
rules in apache to protect n sites.

IMHO Magnolia's security would benefit if it made this configuration explicit: 
i.e. by default don't allow "cross-site" and "cross-dms" accesses unless 
explicitly configured to do so in the mappings of the site-definition.

Regards from Vienna,

Richard


Von: [email protected] [mailto:[email protected]] 
Im Auftrag von Will Scheidegger
Gesendet: Sonntag, 12. August 2012 14:06
An: Magnolia User-List
Betreff: Re: [magnolia-user] Re: Multi site, site definitions and the mapping 
configuration

Digging further:

So according to [3] the proper ACL pattern should in fact be 
"<mysite>/path/to/some/page"

As stated in my previous posts, this did not work (at least not as expected on 
my development machine). So I examined a bit further what URISecurityFilter / 
AccessManager was doing. SimpleUrlPattern is used to check if a rule matches or 
not. SimpleUrlPattern in fact is site-aware now. It looks for a <sitename> in 
its constructor and sets the site. From there on it not only checks if the URI 
matches pattern, but it also checks if the site name matches. However it gets 
the current site name by calling 
ExtendedAggregationState.getSiteBasedOnDomain(String domain), so it needs a 
domain name set in the site in order to work. This is probably all right for a 
system properly set up on a productive server, but not for development and in 
most environments not for testing / integration either since domain names are 
most likely not correct there.

Is there a reason why ExtendedAggregationState.getSite().getName() is not used 
for it. After all, the multiSite filter is located before the uriSecurity 
filter in the filter chain and it does a good job determining the site to be 
used with or without domain names.

I modified the SimpleUrlPattern class in this area and afterwards everything I 
tested was working fine. Before I create an JIRA issue with the patch I wanted 
to ask you guys if I am missed something...?
Thanks!

-will

[3] 
http://documentation.magnolia-cms.com/administration/security/accesscontrollists.html#SiteawareACLs


________________________________
----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: 
<[email protected]<mailto:[email protected]>>
----------------------------------------------------------------


----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to