Open markkolich opened 1 year ago
@pitbulk Perhaps a bit to subtle given the lack of reply, but scrolling up here both @haavar (who mentioned being open to maintaining a fork) and @markkolich both sound like potential co-maintainers?
@pitbulk Need this dependency for Wildfly Server version >= 27
.
Waiting this to be merged.
@markkolich coul you folllow up with comments so this PR can be merge?
@jacqueskpoty no, I am not a maintainer of this library ... I have no merge permissions, I'm just a contributor who opened this PR. Please followup with @pitbulk.
@pitbulk Is this PR going to be merged any time soon?
I don't think it's too much to ask that the user extract the parameters and pass it to the library. That seems easier than for the user to understand how to configure the library for their version of the servlet API.
@haavar I disagree, but feel free to send a PR to my fork (e.g., https://github.com/markkolich/java-saml/pull/1) with your proposed changes and we can review+discuss.
Hi @markkolich, is there an ETA for release, please? When will 3.0.0 be available on Maven, please? Thank you.
Hi @pitbulk, sorry for asking again. How is it going? Do you have some idea when will the jakarta supported available on maven, Thank you.
Any estimation on when will this be merged?
Hi @dsvensson, @markkolich @pitbulk
Is it correct understanding that after #395 merged, I am able to pull com.onelogin 3.0 from Maven which supports jakarta? What's the status now, how much longer to achieve that? Is it the full pull request? https://github.com/SAML-Toolkits/java-saml/pull/395/files#diff-1d18ce5e578972573311127e5969a1b6711cbcfbf3143a3fceee8b7a4e6cbb03
On pull request list, I saw #379 but not #395 https://github.com/SAML-Toolkits/java-saml/pull/379
@markkolich Do you have a #395 branch I can check out? I can try build local lib for testing. And how to potentially contribute to this project? Thank you.
@Jing-Van I have no idea what #397 is about ... feel free to fork this repo and open your own PR. Just don't expect it to be merged lol 😃
As stated above, I am not a maintainer of this library and I have no merge permissions. I'm just a contributor who opened a PR over a weekend to try and address https://github.com/SAML-Toolkits/java-saml/issues/349 and https://github.com/SAML-Toolkits/java-saml/pull/115 which was blocking Jakarta adoption in a few of my projects.
Anyways, please read up on the current status of java-saml
as a project in https://github.com/SAML-Toolkits/java-saml/issues/388. Some good context there on where things stand.
Hi @markkolich ,
sorry, I mean #395.
I plan to migrate it to support jakarta.
Do you know is there a branch which tracked the most updated contributes from #349 #115 and #388? May I have your email address, please or we continue discussing here for now.
Thank you.
@markkolich , @dsvensson , @mauromol, @haavar let's solve this situation.
Please, if you are interested in becoming a maintainer/collaborator of the Java-Saml toolkit, send me an email to the address in my Github Profile and share your availability with me for next week, to have a meeting.
Let's discuss the next steps and a roadmap to revive this project.
I am in.
@markkolich , @dsvensson , @mauromol, @haavar let's solve this situation.
Please, if you are interested in becoming a maintainer/collaborator of the Java-Saml toolkit, send me an email to the address in my Github Profile and share your availability with me for next week, to have a meeting.
Let's discuss the next steps and a roadmap to revive this project.
Hi,
@markkolich , @dsvensson , @mauromol, @haavar, @pitbulk Based on profile, Me and @markkolich are both PST time zone. @pitbulk and @dsvensson are both Central European Summer Time 9am PST is 6pm Central European Summer Time. Is that a good time for everyone? If we all need to meet online. I am probably the latest into this thread, I have checked the markkolich:master and I am studying the source code now.
Thank you.
I'm on PDT, and 9AM PDT works for me, but I'm pretty flexible.
Hi @markkolich
I checked out https://github.com/markkolich/java-saml/tree/master
Currently there are tests which fail and some owasp issues. What's the status now? I was thinking to build a local libs of java-saml-servlet-jakarta java-saml java-saml-core as temp solutions.
I believe it should take less time than using a new lib such as keycloak.
Can you shed some lights? If I go through source code, fix bug one by one. How far am I? If the long solution is not too far away, then work on long solution directly.
Thank you. ERROR] Failed to execute goal org.owasp:dependency-check-maven:8.4.0:check (default) on project java-saml-core: [ERROR] [ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '7.0': [ERROR] [ERROR] azure-core-1.46.0.jar: CVE-2023-36052(8.6) [ERROR] azure-core-http-netty-1.14.0.jar: CVE-2023-36052(8.6) [ERROR] azure-identity-1.13.0.jar: CVE-2023-36415(8.8), CVE-2023-36052(8.6) [ERROR] azure-json-1.1.0.jar: CVE-2023-36052(8.6) [ERROR] logback-core-1.4.7.jar: CVE-2023-6378(7.5) [ERROR]
Built my own libs for now :)
My 2 cents. You can treat it as a java project and migrate to support jakarta similarly as if you were migrating your other java project. Samilar methodologies applies. You can make one work during the time before the official release come out.
If you are already using this library, switching to others such as Keycloak introduces significant changes and is unlikely to be implemented within 1-2 weeks, especially if you are already loaded with daily tasks and lack dedicated hours for it.
Any idea, by when this change will be available in maven ?
Another proposed solution for https://github.com/SAML-Toolkits/java-saml/issues/349 and https://github.com/SAML-Toolkits/java-saml/pull/115.
servlet-jakarta
andservlet-javax
which provide differing implementations of the coreHttpRequest
andHttpResponse
interfaces depending on the servlet container implementation where the library is consumedcore
andtoolkit
codecore
andtoolkit
3.0.0
With this change, if you're on a container pre-EE9, then you declare a dependency on:
If you're on an EE9 or later container, then you declare a dependency on:
Of course, this PR also opens the door to non-servlet container implementations, meaning someone in Akka, Play, etc. could use this library as well as long as they provide their own
HttpRequest
andHttpResponse
implementation. The servlet API dependency incore
andtoolkit
has been completely removed.Usage on pre-EE9 containers look like this:
EE9 and later usage looks like this: