News for hackers. Stuff that matters.
Re:Spring 6.1 now compatible with virtual threads and JDK 21... by zapnuk on Wednesday August 16, 2023 @02:05PM (#37151125)
Sometimes the spring way is also just ugly, or confusing if you just want to do thing X. This code here is used for making HTTP requests using OAuth2. There are probably other ways to do it but I've seen this code in more than one place. I speculate that most people didn't knew they had to use a "AuthorizedClientServiceOAuth2AuthorizedClientManager", but rather found an implementation online and copied it.

But as you pointed out, since there are established spring ways to do something, it doen't matter if it's ugly since it actually "just works".

```

@Bean

public AuthorizedClientServiceOAuth2AuthorizedClientManager authorizedClientServiceAndManager (

        ClientRegistrationRepository,
        clientRegistrationRepository,
        OAuth2AuthorizedClientService authorizedClientService) {

    OAuth2AuthorizedClientProvider authorizedClientProvider =
            OAuth2AuthorizedClientProviderBuilder.builder()
                    .clientCredentials()
                    .build();

    AuthorizedClientServiceOAuth2AuthorizedClientManager authorizedClientManager =
            new AuthorizedClientServiceOAuth2AuthorizedClientManager(
                    clientRegistrationRepository, authorizedClientService);
    authorizedClientManager.setAuthorizedClientProvider(authorizedClientProvider);

    return authorizedClientManager;
}

```

Re:Spring 6.1 now compatible with virtual threads and JDK 21... by vbezhenar on Wednesday August 16, 2023 @02:46PM (#37151756)
Now make it with user-configurable credentials (like extracted from database) with proper token caching.

With similar code I almost made a vulnerability in my app because Spring cached tokens which belong to different users.

Spring security is terrible piece of code. Spring - I can stand it. Spring Security - I can not. It was different project back in the day (Acegi Security if I remember correctly). It should have stayed that way.

Re:Spring 6.1 now compatible with virtual threads and JDK 21... by zapnuk on Wednesday August 16, 2023 @03:16PM (#37152191)
This already uses user-configurable credentials. It uses an autowired "ClientRegistrationRepository" that provides the credentials.

We load the credentials once from AWS SecretsManager but I'm sure you could also load them from some DB.

But yes, I'd probably prefern a modern rewrite of Spring Security.

Re:Spring 6.1 now compatible with virtual threads and JDK 21... by sverhagen on Wednesday August 16, 2023 @06:52PM (#37154935)
And yet, it is probably still much more secure than what 90% of us can whip together. I mean, maybe there's something better out there. I'm just pushing back on any suggestions that you should rather roll your own. Because, unless you're the other 10%, in an organization where continuity of that skill-set is taken care of, you definitely should not.
Re:Spring 6.1 now compatible with virtual threads and JDK 21... by FlyingSnake on Wednesday August 16, 2023 @03:14PM (#37152158)
Tangential but I really wish HN supported monospaced code blocks using 3 backticks. Reading code blocks on a phone is terrible here on HN
Re:Spring 6.1 now compatible with virtual threads and JDK 21... by gabereiser on Wednesday August 16, 2023 @06:38PM (#37154826)
You can do it with 3 spaces in front. Not the same as backticks but works just as good…

   public class See {
      public See() {
      }
   }
You just have to use a scratch
Re:Spring 6.1 now compatible with virtual threads and JDK 21... by switch007 on Wednesday August 16, 2023 @04:12PM (#37153039)
I usually begin to rant about the verbosity and unintuitive ways of overriding things in Spring when I have to do it, but then stop and realise I'm grateful that it's actually possible and I don't have to throw out the framework or do some extremely ugly hacks.