From michiel at trimpe.nl Tue Dec 2 17:56:06 2008 From: michiel at trimpe.nl (Michiel Trimpe) Date: Tue Dec 2 18:07:18 2008 Subject: [Hippoportal-dev] How to make SiteMapItem resolving work by exact instead of partial matching. Message-ID: <990c65350812020856i5cd0e140jfdd89ea48fdfc2ce@mail.gmail.com> We're having a problem with the way SiteMapItems are resolved in our Hippo Portal implementation. At the moment when we have a sitemap item like /level1/level2 and we get a request for /level1/level2/non-existent-level3 Hippo Portal treats the request as 'found' and handles it like it was a request for /level1/level2 instead of returning a 404. I've traced it down to line 222 in CMSApplicationRegistryImpl where the following line is called: smi = resolveSiteMapItem(site, path, user, portalUrl, locale, false, usePortalUrl ); where the "false" parameter indicates non-exact matching. Since this parameter is hard-coded, is there any way to force exact matching so that non-existent URLs result in a 404? Kind regards, Michiel Trimpe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081202/12ed1137/attachment.htm From j.hoffman at onehippo.com Wed Dec 3 10:23:47 2008 From: j.hoffman at onehippo.com (Jeroen Hoffman) Date: Wed Dec 3 10:29:28 2008 Subject: [Hippoportal-dev] How to make SiteMapItem resolving work by exact instead of partial matching. In-Reply-To: <990c65350812020856i5cd0e140jfdd89ea48fdfc2ce@mail.gmail.com> References: <990c65350812020856i5cd0e140jfdd89ea48fdfc2ce@mail.gmail.com> Message-ID: <49365023.4000605@onehippo.com> Hi, I think that this non-exact matching was implemented on purpose, but to know for sure we'll have to wait for the person who wrote it, which will take a couple of days. Anyway there is no configuration setting that enforces exact matching, the best solution I can think of is to create your own implementation of CMSApplicationRegistry, overriding the method. Regard, Jeroen Hoffman Michiel Trimpe wrote: > We're having a problem with the way SiteMapItems are resolved in our > Hippo Portal implementation. > > At the moment when we have a sitemap item like /level1/level2 and we get > a request for /level1/level2/non-existent-level3 Hippo Portal treats the > request as 'found' and handles it like it was a request for > /level1/level2 instead of returning a 404. > > I've traced it down to line 222 in CMSApplicationRegistryImpl where the > following line is called: > smi = resolveSiteMapItem(site, path, user, portalUrl, > locale, false, usePortalUrl ); > where the "false" parameter indicates non-exact matching. > > Since this parameter is hard-coded, is there any way to force exact > matching so that non-existent URLs result in a 404? > > Kind regards, > > Michiel Trimpe > > > ------------------------------------------------------------------------ > > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev From michiel at trimpe.nl Wed Dec 10 10:53:23 2008 From: michiel at trimpe.nl (Michiel Trimpe) Date: Wed Dec 10 10:53:32 2008 Subject: [Hippoportal-dev] How to make SiteMapItem resolving work by exact instead of partial matching. In-Reply-To: <49365023.4000605@onehippo.com> References: <990c65350812020856i5cd0e140jfdd89ea48fdfc2ce@mail.gmail.com> <49365023.4000605@onehippo.com> Message-ID: <990c65350812100153y3dd1058h86863755a1e99974@mail.gmail.com> Hi, I was almost going to reply that we can't override CMSApplicationRegistry because we can't extend hippo-portal.war, since we're working in Maven 2 and only have access to the raw WAR file (which we manually unpacked and modified using maven-assembly-plugin). Last night I got a bit obsessive though and figured out a way to do it anyhow using the org.appfuse:maven-warpath-plugin and the maven-war-plugin's overlay configuration. I thought you might like to know about this so you can find my solution in this pastie: http://pastebin.com/d6c2bb85b Regards, Michiel On Wed, Dec 3, 2008 at 10:23 AM, Jeroen Hoffman wrote: > Hi, > > I think that this non-exact matching was implemented on purpose, but to > know for sure we'll have to wait for the person who wrote it, which will > take a couple of days. > > Anyway there is no configuration setting that enforces exact matching, the > best solution I can think of is to create your own implementation of > CMSApplicationRegistry, overriding the method. > > Regard, > Jeroen Hoffman > > > Michiel Trimpe wrote: > >> We're having a problem with the way SiteMapItems are resolved in our Hippo >> Portal implementation. >> >> At the moment when we have a sitemap item like /level1/level2 and we get a >> request for /level1/level2/non-existent-level3 Hippo Portal treats the >> request as 'found' and handles it like it was a request for /level1/level2 >> instead of returning a 404. >> >> I've traced it down to line 222 in CMSApplicationRegistryImpl where the >> following line is called: >> smi = resolveSiteMapItem(site, path, user, portalUrl, >> locale, false, usePortalUrl ); >> where the "false" parameter indicates non-exact matching. >> >> Since this parameter is hard-coded, is there any way to force exact >> matching so that non-existent URLs result in a 404? >> >> Kind regards, >> >> Michiel Trimpe >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Hippoportal-dev mailing list >> Hippoportal-dev@lists.hippo.nl >> http://lists.hippo.nl/mailman/listinfo/hippoportal-dev >> > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081210/57f2dd99/attachment.htm From helpdesk at onehippo.com Thu Dec 18 15:36:58 2008 From: helpdesk at onehippo.com (JIRA (Ate Douma)) Date: Thu Dec 18 15:49:03 2008 Subject: [Hippoportal-dev] [JIRA] Reopened: (PORTAL-92) Simplify algorithm for resolving CMSRequestContext In-Reply-To: <4164290.1226326258598.JavaMail.jira@hat01> Message-ID: <21822895.1229611018758.JavaMail.jira@hat01> [ http://issues.onehippo.org/browse/PORTAL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma reopened PORTAL-92: ----------------------------- As result of this refactoring, the security configuration and checks for sites not requiring authentication (without a requiredLoginPath) now do require defining a / publicPath to access any sitemap item. Additionally, this has some minor side-effects on the ResourceServlet handling of publicPath access. These effects needs to be reviewed to see if we can somehow restore backwards compatibility (e.g. not needing to define a / publicPath for sites without required authentication). > Simplify algorithm for resolving CMSRequestContext > -------------------------------------------------- > > Key: PORTAL-92 > URL: http://issues.onehippo.org/browse/PORTAL-92 > Project: Hippo Portal > Issue Type: Improvement > Components: hippo-portal > Reporter: Dennis Dam > Assignee: Dennis Dam > Fix For: 1.07.01, 1.10.00.m02 > > > The method resolve() in CMSApplicationRegistryImpl contains a lot of redundant code. Resolving this issue can lead to reducing the amount of code by more than 50%. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.onehippo.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From helpdesk at onehippo.com Thu Dec 18 15:36:58 2008 From: helpdesk at onehippo.com (JIRA (Ate Douma)) Date: Thu Dec 18 15:49:03 2008 Subject: [Hippoportal-dev] [JIRA] Updated: (PORTAL-92) Simplify algorithm for resolving CMSRequestContext In-Reply-To: <4164290.1226326258598.JavaMail.jira@hat01> Message-ID: <14399006.1229611018782.JavaMail.jira@hat01> [ http://issues.onehippo.org/browse/PORTAL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma updated PORTAL-92: ---------------------------- Priority: High (was: Normal) > Simplify algorithm for resolving CMSRequestContext > -------------------------------------------------- > > Key: PORTAL-92 > URL: http://issues.onehippo.org/browse/PORTAL-92 > Project: Hippo Portal > Issue Type: Improvement > Components: hippo-portal > Reporter: Dennis Dam > Assignee: Dennis Dam > Priority: High > Fix For: 1.07.01, 1.10.00.m02 > > > The method resolve() in CMSApplicationRegistryImpl contains a lot of redundant code. Resolving this issue can lead to reducing the amount of code by more than 50%. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.onehippo.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From helpdesk at onehippo.com Mon Dec 29 10:58:58 2008 From: helpdesk at onehippo.com (JIRA (Dennis Dam)) Date: Mon Dec 29 10:58:21 2008 Subject: [Hippoportal-dev] [JIRA] Updated: (PORTAL-92) Simplify algorithm for resolving CMSRequestContext In-Reply-To: <4164290.1226326258598.JavaMail.jira@hat01> Message-ID: <11506702.1230544738878.JavaMail.jira@hat01> [ http://issues.onehippo.org/browse/PORTAL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Dam updated PORTAL-92: ----------------------------- Fix Version/s: (was: 1.07.01) 1.07.02 Affects Version/s: 1.07.01 1.10.00m01 > Simplify algorithm for resolving CMSRequestContext > -------------------------------------------------- > > Key: PORTAL-92 > URL: http://issues.onehippo.org/browse/PORTAL-92 > Project: Hippo Portal > Issue Type: Improvement > Components: hippo-portal > Affects Versions: 1.07.01, 1.10.00m01 > Reporter: Dennis Dam > Assignee: Dennis Dam > Priority: High > Fix For: 1.07.02, 1.10.00.m02 > > > The method resolve() in CMSApplicationRegistryImpl contains a lot of redundant code. Resolving this issue can lead to reducing the amount of code by more than 50%. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.onehippo.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From helpdesk at onehippo.com Mon Dec 29 11:00:58 2008 From: helpdesk at onehippo.com (JIRA (Dennis Dam)) Date: Mon Dec 29 11:00:22 2008 Subject: [Hippoportal-dev] [JIRA] Resolved: (PORTAL-92) Simplify algorithm for resolving CMSRequestContext In-Reply-To: <4164290.1226326258598.JavaMail.jira@hat01> Message-ID: <22368017.1230544858668.JavaMail.jira@hat01> [ http://issues.onehippo.org/browse/PORTAL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Dam resolved PORTAL-92. ------------------------------ Resolution: Fixed changes to the check whether login is required or not, are reverted to maintain backward compatiblity. Right now the default behaviour is : - if not requiredLoginPath is defined for the Site, then the whole site is public. - if a requiredLoginPath is defined, then the whole site is secure (requiring login for all pages), except for those pages which' urls are specified in the "public paths" list of the site Note: I didn't change the way resources are served, since my that code was not affected as far as I could see. Right now resources are always public, unless a requiredLoginPath is configured for the site. This is the same way a hippo-cocoon based website functions by the way. It is my opinion that we need a separate mechanism for securing binary resources from the repository. I will create a separate issue for it. > Simplify algorithm for resolving CMSRequestContext > -------------------------------------------------- > > Key: PORTAL-92 > URL: http://issues.onehippo.org/browse/PORTAL-92 > Project: Hippo Portal > Issue Type: Improvement > Components: hippo-portal > Affects Versions: 1.07.01, 1.10.00m01 > Reporter: Dennis Dam > Assignee: Dennis Dam > Priority: High > Fix For: 1.07.02, 1.10.00.m02 > > > The method resolve() in CMSApplicationRegistryImpl contains a lot of redundant code. Resolving this issue can lead to reducing the amount of code by more than 50%. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.onehippo.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From helpdesk at onehippo.com Mon Dec 29 11:11:58 2008 From: helpdesk at onehippo.com (JIRA (Dennis Dam)) Date: Mon Dec 29 11:11:25 2008 Subject: [Hippoportal-dev] [JIRA] Created: (PORTAL-96) Secure resource urls Message-ID: <21640489.1230545518611.JavaMail.jira@hat01> Secure resource urls -------------------- Key: PORTAL-96 URL: http://issues.onehippo.org/browse/PORTAL-96 Project: Hippo Portal Issue Type: New Feature Components: hippo-portal, hippo-portal-j2 Affects Versions: 1.10.00m01, 1.07.01 Reporter: Dennis Dam Assignee: Dennis Dam Fix For: 1.10.00.m02 We need a mechanism to secure resource urls. Right now, resources are only secured when the required login path is configured for a site. There are two problems with this approach: 1. this solution is too coarse-grained: either all resources required a login, or all resources are public. 2. required loginpath is not relevant for resources; in my opinion, the required login path is a separate security mechanism which should only be used for securing urls derived from the sitemap, not for resources Several ideas for a new resource security mechanism: # "mount" binaries path under a sitemap item. This way we can maintain the same required login path / public urls approach as for sitemap urls # provide a separate configuration for resource urls. For example, a boolean flag "secureResources", with a separate list of urls which are exceptions. So if the flag would be 'true', the exceptions would be public urls, if the flag is 'false' , the urls would be secure urls. In either case, the end result should be that it's easy to either make all binaries secure, except for some binary paths which are public, OR make all binaries public, except from some binary paths which are secure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.onehippo.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From helpdesk at onehippo.com Mon Dec 29 11:13:58 2008 From: helpdesk at onehippo.com (JIRA (Dennis Dam)) Date: Mon Dec 29 11:13:21 2008 Subject: [Hippoportal-dev] [JIRA] Commented: (PORTAL-96) Secure resource urls In-Reply-To: <21640489.1230545518611.JavaMail.jira@hat01> Message-ID: <25686924.1230545638645.JavaMail.jira@hat01> [ http://issues.onehippo.org/browse/PORTAL-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_45420 ] Dennis Dam commented on PORTAL-96: ---------------------------------- see also PORTAL-92 > Secure resource urls > -------------------- > > Key: PORTAL-96 > URL: http://issues.onehippo.org/browse/PORTAL-96 > Project: Hippo Portal > Issue Type: New Feature > Components: hippo-portal, hippo-portal-j2 > Affects Versions: 1.07.01, 1.10.00m01 > Reporter: Dennis Dam > Assignee: Dennis Dam > Fix For: 1.10.00.m02 > > > We need a mechanism to secure resource urls. Right now, resources are only secured when the required login path is configured for a site. There are two problems with this approach: > 1. this solution is too coarse-grained: either all resources required a login, or all resources are public. > 2. required loginpath is not relevant for resources; in my opinion, the required login path is a separate security mechanism which should only be used for securing urls derived from the sitemap, not for resources > Several ideas for a new resource security mechanism: > # "mount" binaries path under a sitemap item. This way we can maintain the same required login path / public urls approach as for sitemap urls > # provide a separate configuration for resource urls. For example, a boolean flag "secureResources", with a separate list of urls which are exceptions. So if the flag would be 'true', the exceptions would be public urls, if the flag is 'false' , the urls would be secure urls. > In either case, the end result should be that it's easy to either make all binaries secure, except for some binary paths which are public, OR make all binaries public, except from some binary paths which are secure. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.onehippo.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira