Hello everyone,
we discussed on the biweekly whether there is a way to have pull
requests marked as not-ready to merge. Gitlab supports this: if you
prefix the merge request with "WIP:" (work in progress) it will
disable the merge button. Github has a similar feature called draft
pull requests. You can read more about it here:
https://help.github.com/en/articles/about-pull-requests#draft-pull-requests
I suggest we make use of this wherever needed ;)
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hola a todos!
Thank you for filling out the poll. The best time (but not perfect) is Thursday, 16 May 2019 @ 14:00 UTC. I’ve sent a calendar invitation to the individuals who usually attend the calls; if you have not received one and would like a calendar invite, please let me know!
Connection details for the call are below. I will send out an agenda on Tuesday.
Meeting URL
https://bluejeans.com/163562895?src=join_info
Meeting ID
163 562 895
Want to dial in from a phone?
Dial one of the following numbers:
+1.408.740.7256 (US (San Jose))
+1.408.317.9253 (US (Primary, San Jose))
(see all numbers - https://www.bluejeans.com/premium-numbers)
Enter the meeting ID and passcode followed by #
Connecting from a room system?
Dial: bjn.vc or 199.48.152.152 and enter your meeting ID & passcode
Thanks! Heather
Hola a todos!
Several people have let me know that they are not available during our usual call window on 14 May 2019. I’ve put together a doodle poll to try and find an alternate time; we’ll try and get back to our usual call cycle on 28 May 2019 (pending participants’ availability).
https://doodle.com/poll/rdfawvpi78ce8p9h
If you would fill that out ASAP, I would appreciate it! Some options are for this Friday, so the sooner we have a list of viable choices, the better.
Thanks! Heather
Hi,
I just pushed pysaml2 PR #613 to enable more flexible entity catetory
support:
https://github.com/IdentityPython/pysaml2/pull/613
Before this PR entity category modules to be used to help configure
attribute release for an IdP could only be imported from
the name space saml2.entity_category. This is cumbersome and made
overlaying new entity category modules or custom versions of existing
entity category modules difficult.
With this PR entity category modules are first searched for on the
general module import path. If they are not found there then the current
default of importing from saml2.entity_category.<module> is used.
Thanks,
Scott K
In my effort to clean up pyff (cf recent posts) I have created an
HTML5/JS frontend app that closely mirrors the "admin" application
that pyffd currently comes with: https://github.com/SUNET/mdq-browser
This is another step in the (previously announced) plan to make
core pyFF less of a monolith.
Also the api-refactory has seen a lot of work recently, notably
adding several APIs to help instrument pyFF and a rewrite of the
fetch module to use apscheduler which looks like a great tool for
managing asynchronous operations.
Cheers Leif
Hola a todos!
After much discussion, debate, and research, the Identity Python board (https://idpy.org/organization/) has agreed upon a Note Well [1] to govern contributions to all Identity Python Projects. This Note Well is linked off the Contribute page on our website. See https://idpy.org/contribute/.
Please let me know if you have any questions!
-Heather
[1] Full text:
Identity Python Note Well
version 1 - Approved 1 May 2019 by the Identity Python Board
This is a reminder of Identity Python policies in effect on various topics such as patents or other IPR.
• By participating (e.g., submitting code, attending in conference calls or meetings, posting to project mailing lists) in Identity Python projects, you agree to follow Identity Python processes and policies as defined in the Identity Python governance pages and in the GitHub Terms of Service.
• If you are aware of any code, component or material idea within any of the projects included in Identity Python that is covered by patents or patent applications that are owned or controlled by you, your sponsor, employer or any other organization with which you are affiliated, you have an obligation to disclose that fact, or refrain from contributing to Identity Python.
• By making a contribution to Identity Python you are asserting that you have permission to make such contributions on behalf of your sponsor employer or affiliated organization.
• If you are working on any code component jointly managed with another organization, you agree to abide by that organizations IPR policies and any requirements for a Contributor License Agreement.
• As a participant or attendee, you agree to work respectfully with other participants; please contact the Identity Python board board at idpy.org if you have any questions or concerns.
Hi,
Right now the saml2.py in src/satosa/backends/ has
def disco_query(self):
"""
Makes a request to the discovery server
:type context: satosa.context.Context
:type internal_req: satosa.internal.InternalData
:rtype: satosa.response.SeeOther
:param context: The current context
:param internal_req: The request
:return: Response
"""
return_url = self.sp.config.getattr("endpoints", "sp")["discovery_response"][0][0]
loc = self.sp.create_discovery_service_request(self.discosrv, self.sp.config.entityid, **{"return": return_url})
return SeeOther(loc)
Essentially this restricts the flow to one and only one IdP discovery
service that is configured statically.
I propose that this method be enhanced so that it can inspect the context
and internal data and if it finds a URL for the discovery service to use
it overrides what is in the configuration.
Then one can configure a request microservice that uses some logic to set
the URL for the discovery service, such as which SP the authentication
request came from.
Since the comment for the method already includes a mention of the context
and internal data, I suspect this functionality was designed but never
implemented.
Any objections to me implementing it?
Any other comments or input?
Thanks,
Scott K
