I need to start upgrading my company’s API services to Spring Boot 3 - I’m blocked on doing that until this PR is merged: Upgrade to Spring Security 6, requiring Java 17 and Gradle 7.3 minimum by adrogon · Pull Request #78 · auth0/auth0-spring-security-api · GitHub
It’s been sitting there open for a few days now. Can someone on the team please take a look?
Let me ping the team responsible for that repo and see if they have the bandwidth to take care of it right now!
I had a chance to talk with our engineering team behind this SDK and they were wondering what advantages you find from using that library versus just configuring Spring directly?
Personally, I’m in a situation where I started via the Java quickstart, the quickstart said “Use this library” - and I never really looked back or considered configuring Spring directly.
I think part of it as well is not knowing that a better approach exists. I just looked at the spring quickstart and it’s changed a lot since I last looked at it, no mention of the library at all - so writing on the wall here is that y’all would prefer to turn this library off and just configure spring directly, hence your question
From an org perspective, I have a bunch of teams focused on building software that differentiates us as a business - the more time I can get them working on that stuff the better. Auth code doesn’t differentiate our product so I want to take that off the shelf as much as possible. There’s also an argument for “y’all are the experts in auth, so I want to be able to rely on that expertise in configuring, managing that functionality”.
In other words, less a tech question and more of a buy vs build question + org dynamics vs the dynamics of an individual developer doing a thing
Gotchya! Thank you! Let me relay it to the team and see what they will decide on
Just to add to this @konrad.sopala - looks like the quick start docs are out of date now for Java APIs as well.
Auth0 Spring Boot API SDK Quickstarts: Spring Boot API calls for:
Pretty sure for Spring 6 + Spring Boot 3 mvcMatchers aren’t available any more. Works for Spring Boot 2.7.0 (the version the quick start is on => auth0-spring-security5-api-sample/build.gradle at master · auth0-samples/auth0-spring-security5-api-sample · GitHub )
But not for Spring Boot 3 - so either way, using the library or migrating away from it, I still have a problem
Security code gives me hives - I remember having to rework this code a couple of times with Auth0 - hopefully this change isn’t as bad as the last one.
Thank you for sharing all that! I’m waiting for the information from the team
Here’s what I can relay from the team:
Spring Boot 3 came out pretty recently, so it is correct that the quickstart and sample don’t demonstrate using Spring 6 and Spring Boot 3. We will work to get something in the backlog to update our quickstart and sample for Spring 6
Hi Konrad, with respect, this doesn’t solve my problem, so I’m unmarking your last message as the solution.
I’m still blocked, and the merging of Upgrade to Spring Security 6, requiring Java 17 and Gradle 7.3 minimum by adrogon · Pull Request #78 · auth0/auth0-spring-security-api · GitHub can still unblock me.
The updating of documentation and samples in the quickstart is a separate conversation
If the team aren’t going to merge that PR, you’re essentially saying that:
- Yes, we understand that you are blocked
- Yes, we understand that in the immediate short term merging this PR will unblock you
- We don’t want you to use our published library anymore, even though we don’t have an alternative for you at the moment.
Can you see how this traps me in no man’s land?
I’m happy to move from the library to another method, but it’s hard to hear that the team want me to do that without first providing the alternative.
Absolutely weapons-free to turn that library off, but please don’t block me when the Auth0 team could quickly fix the problem, such that I can migrate later when the preferred option has been released.
Hey @4lexnz !
Sure totally understand you but I also want to share how we approach this. Before you guys actually created this topic there were some talks in the engineering team that is managing team that potentially that this library has been targeted for possible deprecation for quite some time.
As there were a couple of people recently reaching out to us regarding this library but also the PR that we are discussing the team needs to evaluate what will be further steps. As you can imagine in a company of that size working on so many different libraries, SDKs and other products it’s not a matter of just reviewing and merging one PR cause such decision brings specific outcomes and the team needs to simply analyze it in the long term.
As of now I’m not able to provide you with what you expect because of the mentioned reasons. As soon as I know something from the team I’ll make sure to relay it here. Sorry for the inconvenience!
I totally get it and I’m not upset!
I’ve had to make similar decisions in the past and am not trying to tie the hands of the maintaining team!
If there is no solution for now, I don’t like it, it’s not ideal, but I can accept it. But that means we probably ought to not mark a solution for this thread, so that folks who view it later don’t misinterpret and think there is a solution when there isn’t one. That’s all I’m saying
Having the clarity that this has been a conversation the team have been thinking about really helps, and helps ground this thread in that context.
Gotchya! I marked it as a solution for now so that others coming the the forum know what’s the current state for that. We constantly moderate those and change solutions etc. There are a lot of topics in the forum that are marked as solution but we clearly indicate that the engineering team is working on the solution and it should be there in the near future. Sorry for misleading!
Hi @konrad.sopala - any updates on this?