-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactored out Servlet dependencies from core and toolkit #395
base: master
Are you sure you want to change the base?
Conversation
delegate.getSession().invalidate(); | ||
} | ||
|
||
public static HttpRequest makeHttpRequest(HttpServletRequest delegate) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not even sure this static method is really needed, I mean is this really any better than new JakartaSamlHttpRequest(delegate)
?
delegate.sendRedirect(location); | ||
} | ||
|
||
public static HttpResponse makeHttpResponse(HttpServletResponse delegate) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not even sure this static method is really needed, I mean is this really any better than new JakartaSamlHttpResponse(delegate)
?
public final class HttpRequest { | ||
|
||
public static final Map<String, List<String>> EMPTY_PARAMETERS = Collections.<String, List<String>>emptyMap(); | ||
public interface HttpRequest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* | ||
* @since 3.0.0 | ||
*/ | ||
public interface HttpResponse { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
22c228f
to
fbfe69b
Compare
Thanks @markkolich for this PR. Let's see what rest of the people think about it. @veselov, @mauromol, @jeroenvs, @lounagen, @krzysztof-osiecki , @dsvensson, @josemgut, @bramhaag, @fanste |
This works for me. Thank you @markkolich! |
This would also work for me. Thank you! |
Thats seems to be the best solution instead of using the "transformer hack". Thanks for your work, @markkolich. |
This is also good for me. I'm not able to test it inmediatelly, but in two weeks we will apply it and it will work for sure. Thanks a lot. |
I had a quick look at the commit and I would say this is exactly what I had in mind in #349 (comment). So, good job @markkolich Just my 2 cents: maybe the |
@mauromol fair point on request.getSession().invalidate(); Happy to change that to: HttpSession session = delegate.getSession(false);
if (session != null) {
session.invalidate();
} |
d5dbbde
to
0c8040f
Compare
will this be merged anytime soon ? |
@markkolich |
Nice find @ardeleana - I have fixed the bug in this PR and have updated the unit tests accordingly. Thank you! @pitbulk there were also a bunch of |
@mauromol I've been tinkering with the changes you suggested above. I think I understand what you're suggesting, and now that it's implemented the Before: <%@page import="com.onelogin.saml2.Auth"%>
<?
Auth auth = new Auth(request, response);
?> After, with the <%@page import="com.onelogin.saml2.BaseAuth"%>
<%@page import="com.onelogin.saml2.servlet.jakarka.JakartaSamlAuth"%>
<?
BaseAuth auth = new JakartaSamlAuth(request, response);
?> To gently reiterate, this is not a drop-in and make-no-changes to your JSPs backwards compatible change. Users will have to change imports and rename I've pushed the suggested changes to this PR as a separate commit - I can squash if this looks good. |
I just would like to specify that I'm not a maintainer of this project and I cannot merge. Some years ago I would have needed java-saml to be enhanced to properly support Italian SPID system, I've submitted some PRs, most of which have been merged, a couple of them are still there and one was never opened. Unfortunately, OneLogin lost interest in this project, Sixto changed his job, the new maintainers were absent, I even applied myself after being suggested by one of them, but things went in a different way. Probably this project should have been forked at that time, but I didn't have the necessary experience to do that. Now Sixto has come back as an independent maintainer, but it's clear that it is very low priority for him. I myself have changed job and I'm not into SAML and SPID any more, the latter now being pushed towards a migration to OpenID Connect, by the way (if it doesn't get dismissed before). Here I just tried to give my suggestions on how to implement this based on what I know about Sixto point of view, and what I would have done myself. I still believe a solution which does not require any code change for old code should be possible, but I also think that small adjustments could probably be made by Sixto himself if he's willing to. So, if I were you, I would seriously consider to fork this project and push the necessary changes the way you prefer. |
It is not a matter of low priority, I'm sorry about the big delay I gave to this project. As people may know, I maintain in my spare time not only java-saml, but php-saml, ruby-saml and python3-saml. And at the end of the day, it is a matter of time. I had in mind to push this project in December, but sadly I have had not the chance to do it yet. |
You can probably spot 1-2 people in this thread who you can give merge access to to get the ball rolling. No harm in merging and then iterating, throw out a rc and get heated feedback. |
@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 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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we completely remove the HttpRequest
from core? 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.
|
||
import org.apache.commons.lang3.StringUtils; | ||
|
||
public class HttpRequestUtils { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this class used anywhere in core. It should either be moved or removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import java.util.HashMap; | ||
import java.util.Map; | ||
|
||
public class HttpResponseUtils { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this class used anywhere in core. It should either be moved or removed.
@@ -625,7 +625,7 @@ public String login(String relayState, AuthnRequestParams authnRequestParams, Bo | |||
parameters.put("SAMLRequest", samlRequest); | |||
|
|||
if (relayState == null) { | |||
relayState = ServletUtils.getSelfRoutedURLNoQuery(request); | |||
relayState = HttpRequestUtils.getSelfRoutedURLNoQuery(request); | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@haavar The HttpRequestUtils
class is being used here and is heavily used throughout this BaseAuth
class.
@haavar I disagree, but feel free to send a PR to my fork (e.g., markkolich#1) with your proposed changes and we can review+discuss. |
Hi @markkolich, is there an ETA for release, please? |
Hi @pitbulk, sorry for asking again. |
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? On pull request list, I saw #379 but not #395 @markkolich |
@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 #349 and #115 which was blocking Jakarta adoption in a few of my projects. Anyways, please read up on the current status of |
Hi @markkolich , sorry, 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? 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.
|
Hi, @markkolich , @dsvensson , @mauromol, @haavar, @pitbulk 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. I believe it should take less time than using a new lib such as keycloak. Can you shed some lights? Thank you. |
Built my own libs for now :) My 2 cents. 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 #349 and #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: