Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

[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...

  • No labels