[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