[11:26:30 CDT(-0500)] <jwennmacher> EricDalquist: As part of the modifications for capturing the originally requested url and and trying to return to that page after login, I'm trying to figure out if there is a way to determine IF the user must login to access the original url. Would the UrlSyntaxProviderImpl.getCononicalUrl method do that?
[11:26:46 CDT(-0500)] <EricDalquist> not really
[11:26:50 CDT(-0500)] <EricDalquist> we've talked about that a lot
[11:26:56 CDT(-0500)] <EricDalquist> and we don't have a great way to do it right now
[11:27:06 CDT(-0500)] <EricDalquist> the url builder builds the url for what the current user can see
[11:28:53 CDT(-0500)] <jwennmacher> You mean PortalUrlProviderImpl?
[11:29:03 CDT(-0500)] <EricDalquist> right
[11:33:20 CDT(-0500)] <jwennmacher> I'm curious. If I compare the requested url to the one output by UrlSyntaxProviderImpl.generateUrl when would they be different but the original URL is a valid one you can display to a guest user?
[11:33:36 CDT(-0500)] <EricDalquist> so they URLs might be different
[11:33:39 CDT(-0500)] <EricDalquist> but you have no idea why
[11:33:49 CDT(-0500)] <EricDalquist> what would need to happen is
[11:34:18 CDT(-0500)] <EricDalquist> modify the url syntax provider to generate the request info object without doing permission checks
[11:34:29 CDT(-0500)] <EricDalquist> then filter that object using permission checks
[11:34:36 CDT(-0500)] <EricDalquist> and if they are different
[11:34:41 CDT(-0500)] <EricDalquist> you know you need to auth
[11:35:02 CDT(-0500)] <EricDalquist> right now the permission filtering happens while the request info object is being built
[11:35:17 CDT(-0500)] <EricDalquist> so you never have access to an object model of the actual original url
[11:35:40 CDT(-0500)] <EricDalquist> and that is hard right now because of how tightly coupled the authz logic is in various places
[11:35:50 CDT(-0500)] <EricDalquist> so none of this is out of the realm of possibility
[11:36:03 CDT(-0500)] <EricDalquist> its just that the authz checks around what you can/cant see needs to be reworked
[11:47:50 CDT(-0500)] <drewwills> I haven't looked at the class, but that sounds doable to me
[11:48:00 CDT(-0500)] <EricDalquist> it is
[11:48:04 CDT(-0500)] <EricDalquist> but it is more than just that class
[11:48:19 CDT(-0500)] <EricDalquist> you would need to touch the portlet definition, entity, and window registry classes
[11:48:27 CDT(-0500)] <EricDalquist> to deal with the authz filtering
[11:48:36 CDT(-0500)] <EricDalquist> since it exists in some form at several levels
[11:49:18 CDT(-0500)] <drewwills> hmm... ok
[11:49:32 CDT(-0500)] <EricDalquist> so there isn't any authz checking in the url syntax provider
[11:49:35 CDT(-0500)] <drewwills> did you happen to see the msg I posted yesterday?
[11:49:46 CDT(-0500)] <EricDalquist> it is just relying on the fact that if it asks for example for a portlet window for an fname
[11:49:56 CDT(-0500)] <EricDalquist> and the user doesn't have permision
[11:49:59 CDT(-0500)] <EricDalquist> it just gets null back
[11:50:05 CDT(-0500)] <EricDalquist> as a rough example
[11:50:06 CDT(-0500)] <EricDalquist> um
[11:50:09 CDT(-0500)] <EricDalquist> I don't think so
[11:50:15 CDT(-0500)] <EricDalquist> yesterday afternoon was all sprint planning
[11:50:22 CDT(-0500)] <drewwills> gotcha... the ability to ignore authZ would have to be baked into 2-3 other types that the URL builder uses
[11:50:51 CDT(-0500)] <EricDalquist> correct
[11:50:55 CDT(-0500)] <EricDalquist> and very carefully
[11:51:06 CDT(-0500)] <EricDalquist> since LOTS of stuff in the portal assumes those types do AuthZ checking
[11:51:10 CDT(-0500)] <drewwills> working with Kansas, who are interested in making access to the personalization features permissions-based
[11:51:17 CDT(-0500)] <EricDalquist> ok
[11:51:31 CDT(-0500)] <EricDalquist> just use the xslt isMemberOf tags to hide the ui features?
[11:51:44 CDT(-0500)] <drewwills> i don't think it's much trouble really
[11:52:15 CDT(-0500)] <drewwills> i was looking at adding upAuth:hasPermission(owner,activity[,target])
[11:52:40 CDT(-0500)] <EricDalquist> ah yeah
[11:52:42 CDT(-0500)] <EricDalquist> that would work
[11:52:50 CDT(-0500)] <EricDalquist> and more flexible than group based
[11:52:57 CDT(-0500)] <drewwills> extensible too, should we need it
[11:53:00 CDT(-0500)] <drewwills> yeah
[11:53:22 CDT(-0500)] <drewwills> the one thing I wonder about atm...
[11:53:49 CDT(-0500)] <drewwills> should I make 1 perm for access to the "Customize" widget, or 4-6 for access to the different elements within it
[11:53:59 CDT(-0500)] <EricDalquist> hrm
[11:54:07 CDT(-0500)] <drewwills> and then if you don't have access to any, disable it all together
[11:54:31 CDT(-0500)] <EricDalquist> can we do "super" permissions?
[11:54:38 CDT(-0500)] <drewwills> i'm leaning toward the former... because there is already perm infrastructure for what you can do to fragments
[11:54:43 CDT(-0500)] <EricDalquist> like permission X grants you permissions A, B, & C?
[11:55:24 CDT(-0500)] <drewwills> i believe we could do something like that... though it might not be completely transparent in the perm manager
[11:56:00 CDT(-0500)] <EricDalquist> yeah
[11:56:05 CDT(-0500)] <EricDalquist> maybe just one permission for now
[11:56:12 CDT(-0500)] <EricDalquist> it would be easy enough to build it out more if needed later
[11:56:18 CDT(-0500)] <drewwills> i'm starting with the most obvious... single permission to add a tab
[11:56:31 CDT(-0500)] <drewwills> yeah, sounds like a good perspective
[11:57:16 CDT(-0500)] <drewwills> this is not the first time this item has come up... this feature will be very valuable for ssp and anything of that kind
[15:07:55 CDT(-0500)] <jwennmacher> EricDalquist: I'm continuing looking at the refUrl business. Drew had an idea that I might be able to load up a SYSTEM_USER account and run through the url syntax provider, then do the same as the current (guest) user and compare those urls (might need to disregard certain items). Does that seem like that approach would be reasonable to you?
[15:08:24 CDT(-0500)] <EricDalquist> perhaps
[15:08:48 CDT(-0500)] <EricDalquist> I'm not sure how that would actually work but if it does that sounds good
[15:08:53 CDT(-0500)] <EricDalquist> again great care will be needed
[15:09:05 CDT(-0500)] <EricDalquist> to amke sure some error doesn';t result in someone with SYSTEM_USER permissions
[15:09:12 CDT(-0500)] <jwennmacher> I have to look into a few things. I need to verify I can create and destroy session
[15:09:31 CDT(-0500)] <jwennmacher> yeah. There are attributes that look like they might be stored in request as well.
[15:11:20 CDT(-0500)] <EricDalquist> yeah
[15:31:05 CDT(-0500)] <jwennmacher> EricDalquist: As a comparison between the two approach es I started to look into where the permission checks are in the areas you mentioned ... portlet definition, entity, and window registry. By entity do you mean PortletEntityRegistryImpl? For window registry I identified PortletWindowRegistryImpl. I'm not sure where the impact is with portlet definition. I'm assuming you mean whether the user has permissions to view
[15:31:21 CDT(-0500)] <EricDalquist> correct
[15:31:39 CDT(-0500)] <jwennmacher> So it's these two classes or is there a third?
[15:31:57 CDT(-0500)] <EricDalquist> there should be a PortletDefinitionRegistryImpl as well