Timestamps are in GMT/BST.
[6:47] -card.freenode.net- *** Looking up your hostname...
[6:47] -card.freenode.net- *** Checking Ident
[6:47] -card.freenode.net- *** Found your hostname
[6:47] -card.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:48] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:48] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:17] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:06] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:26] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) Quit (Quit: Leaving.)
[15:40] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) has joined #duraspace
[16:57] * vtkeithg (~vtkeithg@2001:468:c80:a103:41e7:ca94:54ec:46d6) Quit (Remote host closed the connection)
[16:57] * vtkeithg (~vtkeithg@2001:468:c80:a103:6813:99bd:98d4:4486) has joined #duraspace
[19:01] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:54] <tdonohue> Hi all, reminder that at the top of the hour, we have our DSpace Devel meeting here : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-18
[19:57] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[19:58] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[19:59] * keithgilbertson (a6f82502@gateway/web/freenode/ip.166.248.37.2) has joined #duraspace
[20:00] <tdonohue> Hi all, it's that time again. DSpace Developer Meeting starts now. https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-18
[20:00] <kompewter> [ DevMtg 2012-04-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-18
[20:00] <tdonohue> We'll kick off things as usual with JIRA reviews. https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-986+ORDER+BY+key+ASC
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-986 ] - [#DS-986] Multiple 'Create' clicks creates multiple communities/collections - DuraSpace JIRA
[20:00] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-986+ORDER+BY+key+ASC
[20:00] <tdonohue> starting off with DS-986
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-986 ] - [#DS-986] Multiple 'Create' clicks creates multiple communities/collections - DuraSpace JIRA
[20:00] * PeterDie_ is now known as PeterDietz
[20:01] <mdiggory> shouldn't continuations stop this from happening?
[20:02] <tdonohue> good question. To be honest, I don't know.
[20:02] * sands (~sandsfish@18.189.87.190) has joined #duraspace
[20:02] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:02] <tdonohue> I do like the suggestion for the "simple answer" though. It seems reasonable that we disable the button after it's clicked
[20:03] <tdonohue> (talking about Ds-986 for those who just joined us)
[20:03] <tdonohue> anyone want to volunteer to investigate DS-986 and fix as needed?
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-986 ] - [#DS-986] Multiple 'Create' clicks creates multiple communities/collections - DuraSpace JIRA
[20:04] <tdonohue> hearing no volunteers?
[20:04] <mdiggory> trying to view the video
[20:05] <hpottinger> I'll check it out
[20:05] <tdonohue> ok. Assign Ds-986 to hpottinger for investigation
[20:05] <tdonohue> (thanks hpottinger!)
[20:05] <tdonohue> next up, DS-992
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-992 ] - [#DS-992] Browse by author or subject with special characters - DuraSpace JIRA
[20:06] <tdonohue> looks like the fix for Ds-992 is specified in the first comment
[20:07] <tdonohue> anyone want to take a look & commit it to GitHub?
[20:07] <mhwood> IIRC the 1-argument form is deprecated anyway. Probably for this reason.
[20:10] <tdonohue> oh, I see, the one-argument form of URLEncoder.encode() is deprecated. I didn't quite understand that at first
[20:11] <tdonohue> ok. Anyone here want to look into this one & verify at least? (Though not sure if anyone here is using JSPUI these days)
[20:11] <mdiggory> yea, thats been a bad method for years, feel like they should have dropped it entirely in java
[20:11] <aschweer> I'll take it
[20:12] <tdonohue> ok, assign Ds-992 to aschweer -- thanks aschweer!
[20:12] <tdonohue> Next up, DS-994
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[20:12] <tdonohue> oh, this one is already claimed by hpottinger... any feedback you need, hardy?
[20:13] <hpottinger> two related issues need addressing first
[20:13] <hpottinger> DS-1006 and DS-1007
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1006 ] - [#DS-1006] authorizations via SpecialGroups methods are not properly created if an existing ePerson is found - DuraSpace JIRA
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1007 ] - [#DS-1007] AuthenticationManager.canSelfRegister is problematic with stacked authentication modules - DuraSpace JIRA
[20:14] <hpottinger> actually, just 1007 is standing in the way of 994
[20:15] <tdonohue> ugh. yea, that seems wrong (what is described in Ds-1007). Is there a way to easily clean up that loop, so that canSelfRegister doesn't work that way?
[20:15] <mdiggory> where is AuthenitcationManager.canSelfRegister() used outside the AuthenticationMethods?
[20:15] <mdiggory> just for delivering the UI link to Register?
[20:17] <mdiggory> Guess I'm thinking about the fact that, at least in the XMLUI, different authentication methods should probably be their own aspects.
[20:18] <mdiggory> So if you want PAsswrod Authentication / Registration, you enable that aspect, if you don't you disable it
[20:18] <sands> let's be careful about putting auth logic into the UI layer though.
[20:18] <mdiggory> No, its not in the UI layer
[20:19] <mdiggory> just the presentation of neccessary actions and views
[20:19] <mhwood> No, but that would put it in the "how many places do we have to fix this" layer.
[20:19] <mdiggory> auth logic still in method... its the business tier
[20:19] <mdiggory> ???
[20:20] <tdonohue> +1 sands & mhwood. That seems to unnecessarily complicate how you enable/disable Shibb (or any other auth plugin). Now you'd also have to go enable it in the XMLUI aspects
[20:21] <mdiggory> sigh... totally disagree.
[20:21] <sands> perhaps a flag than any given UI could respond to… but i digress.
[20:22] <tdonohue> also in XMLUI, it looks like the 'register' link may be controlled by config 'xmlui.user.registration=true' and not by "canSelfRegister()"
[20:22] <tdonohue> (that's the 'register' UI link)
[20:22] * helix84 (a@195.113.97.174) has joined #duraspace
[20:22] <mdiggory> we regualarly need to create our own authentication aspects to manage custom authenication cases (CAS, Shib, ...)
[20:23] <mdiggory> otherwise you need to alter the default sitemaps and admin sitemaps just to enable the new functionality.
[20:23] <helix84> this is relevant, too: https://jira.duraspace.org/browse/DS-367
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-367 ] - [#DS-367] processing of Authentication methods is independent of the chosen Login method (when multiple are available) - DuraSpace JIRA
[20:23] <kompewter> [ [#DS-367] processing of Authentication methods is independent of the chosen Login method (when multiple are available) - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-367
[20:24] <sands> (mdiggory: perhaps more of a UI implementation problem than a system architecture one)
[20:24] <helix84> why are there multiple login forms wjen we have stacked auth?
[20:25] <mdiggory> Because different authentications methods require different parameters/headers/so-on
[20:25] <mdiggory> LDAP may use a realm / or not, and realm is nonsensical for basic password auth
[20:26] <helix84> so basically another form field besides login/password?
[20:26] <mhwood> Maybe the proper question is the other way 'round: why do we have stacked auth methods when the user is supposed to choose one?
[20:27] <mdiggory> from our experience, this is where many customizations start to happen.
[20:27] <helix84> mdiggory: BTW for the particular case of LDAP we have LDAPHierarchicalAuth, so there's no need to manualy enter realm
[20:27] <helix84> mdiggory: what other auth methods require additional fields?
[20:28] <tdonohue> +1 mhwood - if the user actually *chooses* an auth method, it seems reasonable that they should only use that auth method (and not everyone in the stack)
[20:28] <tdonohue> err "everything in the stack" I mean
[20:28] <mhwood> I think maybe the underlying problem for several of these is that we don't really want them stacked; we want alternates. You choose one, one gets called.
[20:29] <tdonohue> +1 mhwood
[20:29] <hpottinger> as for Ds-1007, I think we need to be able to tell CanSelfRegister what method we're asking about
[20:29] <mdiggory> mhwood: Its mostly because of combining methods such as password and IP
[20:30] <sands> mm, mhwood, i see your point, but there are cases where the addative nature of the stack is nice (conditionally adding users to groups for instance, based on something other than auth criteria.)
[20:30] <mhwood> Do people combine those? What would that mean?
[20:30] <mdiggory> I may login from my campus desktop and get more permissions, but with IP based auth, the computer I'm at may already have special group mappings I do not get from off campus
[20:30] <sands> right, essentially what mdiggory says.
[20:30] <tdonohue> aha. yea, that's a good point mdiggory
[20:31] <mhwood> That's conflating authentication and authorization, surely?
[20:31] <sands> perhaps though, that's an argument to split authorization out from authentication. #architecturedeepend
[20:31] <mdiggory> mhwood: cha ching
[20:31] <sands> mhwood: yes, i think in practice the two are conflated regularly in dspace.
[20:32] <helix84> mdiggory: what other auth methods require additional fields?
[20:32] <tdonohue> +1 sands (both comments). Unfortunately the AuthenticationPlugins also do some authorization by adding people to "specialGroups"
[20:32] <tdonohue> it's a not-so-good design that's been around for too long
[20:32] <mhwood> So, authorization can combine different sources of information, but you can only sensibly authenticate from one source at a time, no?
[20:33] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) has left #duraspace
[20:33] <tdonohue> correct, mhwood. IPAuthentication is actually more like "IPAuthorization" -- it actually doesn't support authentication
[20:33] <sands> mhwood, i think that's sound thinking.
[20:34] <mdiggory> perhaps IPAuthentication is really just IPAuthorization
[20:34] <sands> sounds right from what i remember.
[20:34] <tdonohue> mdiggory & I think alike (scary) ;)
[20:34] <mdiggory> yikes
[20:34] <hpottinger> DS-1007 and DS-1088 are pretty similar (same logic problem)
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-1007 ] - [#DS-1007] AuthenticationManager.canSelfRegister is problematic with stacked authentication modules - DuraSpace JIRA
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-1088 ] - [#DS-1088] AuthenticationManager.allowSetPassword is problematic with stacked authentication modules - DuraSpace JIRA
[20:35] <tdonohue> So, in reality, our "Authentication Stack" is really a combined stack of Authentication methods & Authorization methods (like IPAuth)
[20:35] <tdonohue> (which is part of the issue here, I believe)
[20:35] <tdonohue> (or at least one of the underlying issues #architectureDeepEnd)
[20:36] <sands> is there a larger conversation here than can be had in between JIRA tickets?
[20:36] <mhwood> It's not unreasonable to have one plugin doing both, but we need to keep clear which is which and not allow the code to do things to authn that only make sense in authz and vice versa.
[20:37] <mhwood> It looks to me as though authn methods should not stack but authz methods can.
[20:38] <sands> mhwood: that sounds right.
[20:38] <helix84> it's possible to stack authn methods as long as they share the same fields
[20:39] <mhwood> No, "stack" here means that each makes a contribution to the session. What would that mean in authn, where the contribution is Yes or No?
[20:39] <mdiggory> in almost all cases, outside of form based authn, access to the http request or servlet User Principal is needed is needed to complete authn.
[20:39] <hpottinger> so, in addition to AuthNmanager, we need an AuthZmanager
[20:39] * tdonohue is conscious that we seem to be going off the Architectural Deep End
[20:40] <sands> all: i unfortunately have to duck out, but don't want to miss anything important on the 3.0 front. i'd like to +1 tim's suggestion on the agenda that we have a special topics meeting on early 3.0 ideas. i think there's a lot to talk about there, esp. with a full point release and all it could encompass.
[20:40] <mhwood> Yes, going deep, but I feel that if we sort out the authn/authz issues then several JIRAs will become easier to address.
[20:40] <tdonohue> I like the concept that perhaps AuthN shouldn't stack (esp. if you are choosing one), whereas AuthZ should stack (likely always)
[20:41] <tdonohue> but, that being said, not sure if there's a valid use case here we'd be missing. So, we may need to think on this more and bring discusison elsewhere? (maybe dspace-devel? or one of these tickets?)
[20:42] <mhwood> Yes, I see some agreement that something should be done, but need of time to go off and think about the "somethings".
[20:42] <tdonohue> +1 -- if anyone comes up with brainstorms/ideas, I say we start up a thread on dspace-devel, and then we can start to build a proposal of "what to do" from that
[20:43] <tdonohue> ok. with that, I'm gonna close out JIRA discussion. Obviously there's a lot of tickets here that require some AuthN / AuthZ talk. If need be, we can always do a "special topic meeting" to dig in deeper -- but, let's brainstorm more on dspace-devel first.
[20:44] <mdiggory> just to finish off with an example
[20:44] <mdiggory> https://circle.ubc.ca/login
[20:44] <kompewter> [ Choose a Login Method ] - https://circle.ubc.ca/login
[20:44] <mdiggory> Register could be centralized into cIRcle login "aspect"
[20:44] <mhwood> Just to add to the fun: methods like LDAP and Shib can also provide identity data (group membership, email, etc).
[20:45] <tdonohue> yep. mhwood -- in fact, they do just that. They both do both AuthN & AuthZ already (IIRC)
[20:45] <mdiggory> so that if disabled, so would register, likewise, parameterized so that it is hidden for section as well
[20:45] <mdiggory> mhwood: that is true and we do use it.
[20:45] <tdonohue> ok. need to move on here. we've spent 30+ mins on this one topic
[20:46] <mdiggory> CAS validation as well does this
[20:46] <sands> cheers all
[20:46] * sands (~sandsfish@18.189.87.190) Quit (Quit: sands)
[20:46] <tdonohue> FYI: I'll be out of the office next week. So, I'd like to find a volunteer to lead next week's DSpace Developers Meeting, as I'll be unable to attend. Anyone interested?
[20:48] <tdonohue> hearing none, I'd suggest you still "self-organize" (if there's enough folks that show up) and do some quick JIRA reviews OR even followup on this AuthN/AuthZ discussion, if you wish
[20:49] <tdonohue> On to 3.0 Planning... We seem to be moving very slowly so far in discussion / planning for 3.0. The Release Team is starting to "self-organize" (which is great!), but we really need to start to nail down what the Committers want to see in 3.0
[20:50] <tdonohue> So, I was curious if others would be interested in having a "3.0 Planning" Special Topics Meeting in a few weeks or so, hopefully even via Skype (Voice only)
[20:51] <tdonohue> was thinking either May 2 or May 9, during the same time as this meeting
[20:52] <hpottinger> either of those dates works for me
[20:52] <mhwood> 9th might be difficult here.
[20:53] <tdonohue> well, if folks like the idea, we could also try and get a day/time nailed down via email.
[20:54] <aschweer> (sorry, need to go to work -- bye all!)
[20:54] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:55] <tdonohue> Anything else anyone wants to bring up with 3.0 stuff? Brainstorms / Ideas? Feel free to also point your brainstorms to dspace-devel or dspace-commit to "get the ball rolling" as need be. So far it's been rather "quiet" in terms of 3.0 :)
[20:57] <tdonohue> Last thing to mention is GitHub stuff. Not sure if anyone has had a chance to read/think about Git Development Models (see the 'dspace-devel' thread I started). Would be good to start to plan out some (very simple) "best practices", just to again "get the ball rolling" with how we'd like to interact with Git/GitHub
[20:57] <tdonohue> dspace-devel thread: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg08665.html
[20:57] <kompewter> [ [Dspace-devel] DSpace + Git Development model ] - http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg08665.html
[20:58] <tdonohue> I've also updated the NetBeans IDE instructions to include Git stuff: https://wiki.duraspace.org/display/DSPACE/IDE+Integration+-+DSpace+and+NetBeans (Could use volunteers to do the same for IDEA & Eclipse, as I don't have much recent experience with either)
[20:58] <kompewter> [ IDE Integration - DSpace and NetBeans - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/IDE+Integration+-+DSpace+and+NetBeans
[20:59] <tdonohue> That's pretty much all I have today. Things have gotten a bit quiet here though (feel like I'm talking to myself) :)
[21:00] <mhwood> I was looking over the NetBeans update. Looks good.
[21:00] <hpottinger> Thanks, tdonohue, everyone, I've got to run, bye!
[21:00] <mdiggory> special topics meeting sounds good.
[21:00] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:01] <mhwood> Yes, special 3.0 topic sounds good.
[21:01] <tdonohue> If anyone has anything else to add / discuss, feel free. We can consider the "official meeting" closed, but can continue any discussions as need be. I'll be around for a bit, at least.
[21:01] <tdonohue> excellent. glad to hear others agree on the 3.0 topic meeting
[21:02] <mhwood> I need to go. Thanks, all!
[21:02] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Quit: Leaving.)
[21:52] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:57] * helix84 (a@195.113.97.174) has left #duraspace
[22:03] * keithgilbertson (a6f82502@gateway/web/freenode/ip.166.248.37.2) Quit (Quit: Page closed)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.