Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
GUACAMOLE-805: Handle OpenID "id_token" parameter regardless of location in URL fragment. #407
These changes add more robust handling of the
The fragment is reformatted from
All other fragments are left untouched.
Let a comment on the JIRA issue but posting here as well.
I apologize @mike-jumper for the double post.
While we are here though I have a follow up question about versioning. Since this PR addresses a large authentication problem preventing people from using OpenID why is it not in the next patch release? If you are setup for 1.1.0 now, then I would expect a patch to come out in 1.1.1 right after the release of 1.1.0 not having to wait until the next minor (feature based) release 1.2.0.
Or are you not doing patch releases?
I briefly read parts of this: https://firstname.lastname@example.org/msg02298.html
At any given time, there are no more than two possible releases in flight:
Whether the project decides to release the next release as 1.1.1 rather than 1.2.0 is a decision to be made following 1.1.0. It would be best if you don't read into the version number any further than a cosmetic representation of the content and compatibility of the release; it does not affect timing.
Changes to the current process
As noted in the thread you link to, there has been occasional discussion of migrating to a process that would allow for bugfix releases. We don't currently have such a process. A lot of thought and preparation would need to go into that decision. It's not out of the question.
What you can do
Contribute. Be involved in the community.
A better place for this would have been the mailing list, where the rest of the community can be present in the discussion. Commenting only on JIRA or GitHub reaches a much smaller audience. Unless the discussion is extremely directly related to the development at hand, this will just drain the energy of the few that can see your comments. If this PR had not yet been merged and you found an issue with the change, this would have been a good place for that. If the merged code did not actually solve the issue and you believe the bug must be reopened, JIRA would be appropriate. It's not the place to discuss release policy.
If you have feedback regarding the next release, constructive ideas for changes to process, etc., the best place for that is the mailing list. The dev@ list is where all development discussion occurs, and that list will be the home of the thread that will be opened following 1.1.0 to discuss release scope.