jasig-ssp IRC Logs-2013-07-24

Owned by Apereo Infrastructure
Last updated: Jul 24, 2013
4 min read

[12:31:06 CDT(-0500)] <JasonElwood> Paul- ok to rebuild Linux CI now to get the latest changes?

[12:31:24 CDT(-0500)] <pspaude1> Yes, no problem. Working locally to reproduce SSP-1530

[12:51:34 CDT(-0500)] <TonyUnicon> Jason FYI, there are a bunch of global actions that can taken from MAP around person search screen that has to be handled all explicitely

[12:51:46 CDT(-0500)] <TonyUnicon> working on those right now, but thats why i havent moved on to the next ticket

[12:52:06 CDT(-0500)] <TonyUnicon> add,edit,delete, filter, all the status change buttons

[12:52:17 CDT(-0500)] <TonyUnicon> need code around them

[12:52:28 CDT(-0500)] <JasonElwood> cool

[12:54:51 CDT(-0500)] <dmccallum54> can i restart linux CI to pick up trusted IP config?

[12:55:02 CDT(-0500)] <JasonElwood> go ahead

[13:40:35 CDT(-0500)] <pspaude1> Jason, still cannot reproduce SSP-1530 locally. I might need manage users access on Linux CI.

[13:40:51 CDT(-0500)] <pspaude1> There is some delay between changing a role and it taking effect at least locally, but even with that I could not force an Access Denied.

[13:41:00 CDT(-0500)] <JasonElwood> ugh

[13:41:28 CDT(-0500)] <pspaude1> Also, noticed an issue where if a previous login stays open it can still do everything the previous permission could do even if the future logins can't. Hope I didn't open a can of worms.

[13:42:45 CDT(-0500)] <JasonElwood> You can log in directly.

[13:43:18 CDT(-0500)] <JasonElwood> On Linux CI: FormerCoach/former, search opens by default, click the My Caseload button, the view changes, click the My Caseload button again

[13:44:51 CDT(-0500)] <pspaude1> No my caseload button on FomerCoach just tried.

[13:45:05 CDT(-0500)] <pspaude1> Oh, wait I see was hiding.

[13:47:31 CDT(-0500)] <pspaude1> Ok got the access denied. Interesting, can't see what role is assigned because I don't have access to manage users.

[13:51:54 CDT(-0500)] <pspaude1> Looks like FormerCoach is a quasi coach/staff.

[13:52:20 CDT(-0500)] <pspaude1> Ok I figured out the errror it happens to support staff no matter what. Try it with Simth Chris.

[13:53:23 CDT(-0500)] <JasonElwood> ah. I can change the role back to see if it goes away.

[13:53:42 CDT(-0500)] <JasonElwood> role is coach, just waiting on the sync

[13:54:24 CDT(-0500)] <pspaude1> Yep reproduced locally. Happens to support staff no matter what.

[13:54:51 CDT(-0500)] <JasonElwood> so more perms changes

[13:54:55 CDT(-0500)] <JasonElwood> maybe

[13:54:58 CDT(-0500)] <pspaude1> Oh, I forgot about the sync that is why it takes a bit.

[13:55:31 CDT(-0500)] <pspaude1> Yeah, seems like it, I'll try tracking it down.

[13:55:57 CDT(-0500)] <JasonElwood> it is kinda logical. support staff wouldn't have a caseload

[13:56:12 CDT(-0500)] <JasonElwood> as long as they can add/edit and search

[13:56:35 CDT(-0500)] <pspaude1> yes it is logical, but the button display logic may not be logical (smile)

[14:02:49 CDT(-0500)] <JasonElwood> Paul- you should have manage users now

[14:04:50 CDT(-0500)] <pspaude1> Cool, now I probably won't need it.

[14:44:22 CDT(-0500)] <pspaude1> Jason, a thing I noticed testing. If you have a login open and the role changes logging out, clicking SSP or refreshing the page the role (once it's synced ) is enforced.

[14:44:38 CDT(-0500)] <pspaude1> However, if you don't do those things you still have access. I just tested and it lets me save MAPS, journals, edit students etc.

[14:44:47 CDT(-0500)] <JasonElwood> interesting

[14:45:34 CDT(-0500)] <pspaude1> Might be problematic for those that want unlmited time on login and/or someone gets fired etc. Someone could do some damage.

[14:45:56 CDT(-0500)] <dmccallum54> SSP isn't going to ask uportal for a new set of permissions for every request

[14:47:08 CDT(-0500)] <pspaude1> That makes sense, as long as its working correctly. I'll crawl back in my hole now.

[14:48:28 CDT(-0500)] <dmccallum54> UPortalSecurityFilter

[14:48:36 CDT(-0500)] <dmccallum54> that thing is triggered by a portlet render request

[14:48:55 CDT(-0500)] <dmccallum54> and is responsible for querying uportal to get the GrantedAuthorties to populate into the user's security context in SSP

[14:49:17 CDT(-0500)] <dmccallum54> which is why, for example, clicking on the SSP nav link causes "correct" permissions to show after permissions have been changed

[14:53:46 CDT(-0500)] <dmccallum54> pspaude1 … do you recall… for dealing with overlapping terms… did that involve anything else beyond the commits associated wth https://issues.jasig.org/browse/SSP-1245 and https://issues.jasig.org/browse/SSP-1223

[14:53:55 CDT(-0500)] <pspaude1> That explains it then. That also the affects the server correct and allow/deny requests?

[14:54:02 CDT(-0500)] <dmccallum54> that would be 0a06d6d25c6271056e24de51b389cc6ed3395afa and 5cac06bc30bdb63ecaf660bfec74bec27d9cbfbe, respectively

[14:54:39 CDT(-0500)] <dmccallum54> sorry… "the server correct and allow/deny requests"?

[14:55:14 CDT(-0500)] <pspaude1> Two questions, It affects the server? and does it relate to it allowing and denying certain API's.

[14:55:38 CDT(-0500)] <dmccallum54> that's a server-side component yes… it affects the permissions cached in the current user's security context

[14:55:50 CDT(-0500)] <pspaude1> As to the term boundaries that is it as far as I'm aware. I'll recheck one sec...

[14:55:59 CDT(-0500)] <dmccallum54> that list of permissions is read into the client when SSP first renders

[14:56:06 CDT(-0500)] <dmccallum54> via the getAuthenticatedUser API, i think

[14:56:28 CDT(-0500)] <dmccallum54> so basically both the server and client are caching whatever your permissions are when you render the SSP portlet

[14:56:58 CDT(-0500)] <dmccallum54> if you render it again, either by reloading the page or navigating to a different portlet and back or logging out and in, i would expect a fresh set of permissions to be taken into consideration

[14:57:58 CDT(-0500)] <pspaude1> Yes it seems that way from testing. Well, that it explains it. Learned alot, thanks!

[15:01:56 CDT(-0500)] <pspaude1> Dan for the term issue, that looks like it. I think the SSP-1245 0a06d6d25c6271056e24de51b389cc6ed3395afa fixed the 404 errors elsewhere, if you want to port it back to non-MAP versions.

[15:02:19 CDT(-0500)] <dmccallum54> thx

[15:04:40 CDT(-0500)] <pspaude1> But, I didn't have older versions to test with to be sure.

[15:04:46 CDT(-0500)] <pspaude1> No problem

[16:55:21 CDT(-0500)] <pspaude1> Dan, do you think we need to make permission changes to staff for caseload (insert for that permission)? And also possibly faculty to deny as default on caseload read?

[16:56:20 CDT(-0500)] <pspaude1> Probably should email Jason. This is for SSP-1530. Otherwise issue will be fixed, the buttons weren't guarded by permission like the rest in search tool.