Difference between revisions of "Talk:Board Meeting Notes 2016-04-05"

From Pumping Station: One Wiki
Jump to: navigation, search
(Entry access: new section)
 
(Entry access)
Line 4: Line 4:
  
 
The ps1rfid code base supports importing member info via an API and caches it locally. Having it use a different API endpoint wouldn't be hard. Derek also was thinking that it could hit LDAP directly instead of going through an intermediary. I don't prefer that design but it is not important for me to agree. The disadvantage is that it ties the entry system to LDAP. If it hits a member management API rather than LDAP directly, we keep the logic for how we do permissions in the member management system without coupling it to whatever technology we use. It could be backed by LDAP or it could handle itself or it could use WebFoo2000. But, consider the case where both the rfid auth api and the member management both use LDAP as the ultimate source. If you have a ps1auth rfid system that can write to the LDAP server, and the member management can write the LDAP server, then you will have to put in crappy logic to have things be consistent. But, one advantage of having ps1rfid hit LDAP directly is that it won't depend on availability of the member management site. That advantage isn't enough for me to like that approach. [[User:Skm|Skm]] ([[User talk:Skm|talk]]) 12:53, 5 April 2016 (CDT)
 
The ps1rfid code base supports importing member info via an API and caches it locally. Having it use a different API endpoint wouldn't be hard. Derek also was thinking that it could hit LDAP directly instead of going through an intermediary. I don't prefer that design but it is not important for me to agree. The disadvantage is that it ties the entry system to LDAP. If it hits a member management API rather than LDAP directly, we keep the logic for how we do permissions in the member management system without coupling it to whatever technology we use. It could be backed by LDAP or it could handle itself or it could use WebFoo2000. But, consider the case where both the rfid auth api and the member management both use LDAP as the ultimate source. If you have a ps1auth rfid system that can write to the LDAP server, and the member management can write the LDAP server, then you will have to put in crappy logic to have things be consistent. But, one advantage of having ps1rfid hit LDAP directly is that it won't depend on availability of the member management site. That advantage isn't enough for me to like that approach. [[User:Skm|Skm]] ([[User talk:Skm|talk]]) 12:53, 5 April 2016 (CDT)
 +
 +
Any discussion of this topic should include member management in general. --[[User:Dbever|Dbever]] ([[User talk:Dbever|talk]]) 13:53, 5 April 2016 (CDT)

Revision as of 13:53, 5 April 2016

Entry access

Please don't throw away work that has already been done, such as psrfid, without evaluating its current features (which do fit some of the description in the meeting agenda) Skm (talk) 12:53, 5 April 2016 (CDT)

The ps1rfid code base supports importing member info via an API and caches it locally. Having it use a different API endpoint wouldn't be hard. Derek also was thinking that it could hit LDAP directly instead of going through an intermediary. I don't prefer that design but it is not important for me to agree. The disadvantage is that it ties the entry system to LDAP. If it hits a member management API rather than LDAP directly, we keep the logic for how we do permissions in the member management system without coupling it to whatever technology we use. It could be backed by LDAP or it could handle itself or it could use WebFoo2000. But, consider the case where both the rfid auth api and the member management both use LDAP as the ultimate source. If you have a ps1auth rfid system that can write to the LDAP server, and the member management can write the LDAP server, then you will have to put in crappy logic to have things be consistent. But, one advantage of having ps1rfid hit LDAP directly is that it won't depend on availability of the member management site. That advantage isn't enough for me to like that approach. Skm (talk) 12:53, 5 April 2016 (CDT)

Any discussion of this topic should include member management in general. --Dbever (talk) 13:53, 5 April 2016 (CDT)