Is there a way to reuse in place validation of Hibernate's implementation of Bean Validation at runtime? - bean-validation

For example, I have got a class:
#Getter
#Setter
class Notification {
private String recipient;
private Channel channel;
enum Channel {
SMS, EMAIL
}
}
I could define my own Validator, for instance:
#Target(TYPE)
#Retention(RUNTIME)
#Constraint(validatedBy = {RecipientValidator.class})
#interface ValidRecipient {
// required arguments of validation annotation
}
class RecipientValidator implements ConstraintValidator<ValidRecipient, Notification> {
#Override
public void initialize(ValidRecipient annotation) {
}
#Override
public boolean isValid(Notification value, ConstraintValidatorContext context) {
boolean result = true;
if (value.getChannel() == SMS) {
return matches(value.getRecipient(), "<phone-number-regexp>");
}
if (value.getChannel() == EMAIL) {
// can I reuse Hibernate's Email Validation there?
return matches(value.getRecipient(), "<email-regexp>");
}
return result;
}
}
Of course I can google regexp of email and copy-paste there but Hibernate's Bean Validation implementation already has the Email Validation (under #Email annotation).
Is there a way to reuse that validation implementation in my custom validator?

There is no official way to reuse a validator in another one.
What you can do though would be to initialize an EmailValidator attribute in initialize() and call its isValid() method in your isValid() method.
Keep in mind that EmailValidator is internal so it might be subject to changes in the future.

Related

Leveraging user context in an IHostedService via DI

I have a series of class libraries that are used in asp.net-core middleware, and in an IHostedService.
To fetch the user context, I can inject IHttpContextAccessor to grab the HttpContext user:
public class MyLibrary
{
public MyLibrary(IHttpContextAccessor accessor)
{
// set the accessor - no problem
}
public async Task DoWorkAsync(SomeObject payload)
{
// get the user from the accessor
// do some work
}
}
To be a little more abstract, I have an IUserAccessor with an HttpUserAccessor implementation:
public class HttpUserAccessor: IUserAccessor
{
IHttpContextAccessor _httpaccessor;
public HttpUserAccessor(IHttpContextAccessor accessor)
{
_httpaccessor = accessor;
}
public string GetUser()
{
// return user from _httpaccessor
}
}
and then MyLibrary does not need an IHttpContextAccessor dependency:
public class MyLibrary
{
public MyLibrary(IUserAccessor accessor)
{
// set the accessor - no problem
}
public async Task DoWorkAsync(SomeObject payload)
{
// get the user from the accessor
// do some work
}
}
My IHostedService is popping message from a queue, where the message includes:
a user context, and
a serialized SomeObject to pass to MyLibrary.DoWorkAsync
So, something like:
public class MyHostedService : IHostedService
{
IServiceScopeProvider _serviceScopeFactory;
public MyHostedService(IServiceScopeFactory serviceScopeFactory)
{
_serviceScopeFactory = servicesScopeFactory;
}
public Task StartAsync(CancellationToken cancellationToken)
{ ... }
public Task StopAsync(CancellationToken cancellationToken)
{ ... }
public async Task ExecuteAsync(CancellationToken stoppingToken)
{
foreach (var message in queue)
{
using (var scope = _serviceScopeFactory.CreateScope())
{
// todo: tell IUserAccessor what message.User is!
var payload = // create a SomeObject from the queue message
var mylibrary = _services.GetRequiredService<MyLibrary>();
await myLibrary.DoWorkAsync(payload);
}
}
}
}
So, my question is, how does MyHostedService store message.User in such a way that a custom IUserAccessor can access it in a thread-safe manner via DI?
how does MyHostedService store message.User in such a way that a custom IUserAccessor can access it in a thread-safe manner via DI?
The thing you're looking for is AsyncLocal<T> - it's like a thread-local variable but scoped to a (possibly asynchronous) code block instead of a thread.
I tend to prefer a "provider" + "accessor" pairing for this: one type that provides the value, and a separate type that reads the value. This is logically the same thing as a React Context in the JS world, though the implementation is quite different.
One tricky thing about AsyncLocal<T> is that you need to overwrite its value on any change. In this case, that's not really a problem (no message processing will want to update the "user"), but in the general case it's important to keep in mind. I prefer storing immutable types in the AsyncLocal<T> to ensure they aren't mutated directly instead of overwriting the value. In this case, your "user" is a string, which is already immutable, so that's perfect.
First, you'll need to define the actual AsyncLocal<T> to hold the user value and define some low-level accessors. I strongly recommend using IDisposable to ensure the AsyncLocal<T> value is unset properly at the end of the scope:
public static class AsyncLocalUser
{
private static AsyncLocal<string> _local = new AsyncLocal<string>();
private static IDisposable Set(string newValue)
{
var oldValue = _local.Value;
_local.Value = newValue;
// I use Nito.Disposables; feel free to replace with another IDisposable implementation.
return Disposable.Create(() => _local.Value = oldValue);
}
private static string Get() => _local.Value;
}
Then you can define a provider:
public static class AsyncLocalUser
{
... // see above
public sealed class Provider
{
public IDisposable SetUser(string value) => Set(value);
}
}
and the accessor is similarly simple:
public static class AsyncLocalUser
{
... // see above
public sealed class Accessor : IUserAccessor
{
public string GetUser() => Get();
}
}
You'll want to set up your DI to point IUserAccessor to AsyncLocalUser.Accessor. You can also optionally add AsyncLocalUser.Provider to your DI, or you can just create it directly.
Usage would go something like this:
foreach (var message in queue)
{
using (var scope = _serviceScopeFactory.CreateScope())
{
var userProvider = new AsyncLocalUser.Provider(); // (or get it from DI)
using (userProvider.SetUser(message.User))
{
var payload = // create a SomeObject from the queue message
var mylibrary = _services.GetRequiredService<MyLibrary>();
await myLibrary.DoWorkAsync(payload);
}
}
}

How to access token additionalInformation to validate expression-based access control

I succesfully added user_id additionnal information on the generated tokens on the authorization server side by implementing a TokenEnhancer. Here is a token generated:
{"access_token":"ccae1713-00d4-49c2-adbf-e699c525d53e","token_type":"bearer","expires_in":31512,"scope":"end-user","user_id":2}
Now, on the Resource server side, which is a completely separate spring project communicating through a RemoteTokenServices, i would like to use theses informations with method expression-based access control. For example i would like to use the added user_id data (it is Spring Data JPA repository for use with Spring Data Rest):
#PreAuthorize("#oauth2.hasScope('admin') or #id == authentication.principal.user_id")
#Override
UserAccount findOne (#P("id") Integer id);
The #oauth2.hasScope('admin') works as expected but the #id == authentication.principal.user_id" part obviously not.
how can i access to the additional data added to the token on expression-based access control ?
So i've found myself. The key interface is UserAuthenticationConverter.
Using the default provided DefaultUserAuthenticationConverter class, we can set a UserDetailsService which is used to set authentication.principal with the UserDetail object returned by the UserDetailsService. Without that, authentication.principal is only set with the token username as a String.
Here is an extract of my ResourceServerConfigAdapter:
#Configuration
#EnableResourceServer
protected static class ResourceServerConfiguration
extends ResourceServerConfigurerAdapter {
#Bean
UserDetailsService userDetailsService () {
return new UserDetailsServiceImpl();
}
#Bean
public UserAuthenticationConverter userAuthenticationConverter () {
DefaultUserAuthenticationConverter duac
= new DefaultUserAuthenticationConverter();
duac.setUserDetailsService(userDetailsService());
return duac;
}
#Bean
public AccessTokenConverter accessTokenConverter() {
DefaultAccessTokenConverter datc
= new DefaultAccessTokenConverter();
datc.setUserTokenConverter(userAuthenticationConverter());
return datc;
}
#Bean
RemoteTokenServices getRemoteTokenServices () {
RemoteTokenServices rts = new RemoteTokenServices();
rts.setCheckTokenEndpointUrl(
"http://localhost:15574/oauth/check_token");
rts.setAccessTokenConverter(accessTokenConverter());
rts.setClientId("client");
rts.setClientSecret("pass");
return rts;
}
...
}
Another method is to override the DefaultUserAuthenticationManager and provide a custom public Authentication extractAuthentication(Map<String, ?> map).
Once this is done, we can use the user data on expression-based access control like that:
#PreAuthorize("#oauth2.hasScope('admin') or #id == authentication.principal.userAccount.id")
#Override
UserAccount findOne (#P("id") Integer id);
Note that userAccount is my original DOMAIN user object. It could be everything the UserDetailsService returns.
EDIT:
To answer to Valentin Despa, here is my UserDetailsService implementation:
#Component
public class UserDetailsServiceImpl implements UserDetailsService {
#Autowired
UserAccountRepository userAccountRepository;
public UserDetails loadUserByUsername (String username)
throws UsernameNotFoundException {
// Fetch user from repository
UserAccount ua = this.userAccountRepository
.findByEmail(username);
// If nothing throws Exception
if (ua == null) {
throw new UsernameNotFoundException(
"No user found having this username");
}
// Convert it to a UserDetails object
return new UserDetailsImpl(ua);
}
}

why #autowired in spring does not need setter method for private instance variable?

I have some code in my spring project as below
#Component
public class DatabaseAccessUtil
{
#Autowired
private DatabaseAccessor databaseAccessor;
}
My concern is how and why #Autowired annotation of spring work without setter method, example:
void setDatabaseAccessor(DatabaseAccessor databaseAccessor)
{
this.databaseAccessor = databaseAccessor;
}
where is spring's miracle? Thanks
It is because the value of the field is injected via Reflection. Field, Method and Constructor are all descendants of java.lang.reflect.AccessibleObject. This class permits access to its private members by setting the accessible flag to true by calling setAccessible(true).
Here is the actual code from AutowiredBeanPostProcessor that does the actual injection
if (value != null) {
ReflectionUtils.makeAccessible(field);
field.set(bean, value);
}
And the source code of ReflectionUtils.makeAccessible(Field)
public static void makeAccessible(Field field) {
if ((!Modifier.isPublic(field.getModifiers()) ||
!Modifier.isPublic(field.getDeclaringClass().getModifiers()) ||
Modifier.isFinal(field.getModifiers())) && !field.isAccessible()) {
field.setAccessible(true);
}
}

Type check in JSR-303 custom validator initialize method

I'm attempting to create a class level JSR-303 validation definition that checks that one property occurs before another in time. Because the this validation only makes sense for Calendar properties I was wondering if it is possible to test the property type in the initialize method.
My annotation definition is:
#Target({TYPE, ANNOTATION_TYPE})
#Retention(RUNTIME)
#Constraint(validatedBy = TemporalSequenceValidator.class)
#Documented
public #interface TemporalSequence {
String message() default "{uk.co.zodiac2000.vcms.constraints.TemporalSequence}";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
String first();
String second();
}
and the validator implementation:
public class TemporalSequenceValidator implements
ConstraintValidator<TemporalSequence, Object> {
private String firstFieldName;
private String secondFieldName;
#Override
public void initialize(final TemporalSequence constraintAnnotation) {
firstFieldName = constraintAnnotation.first();
secondFieldName = constraintAnnotation.second();
// Is it possible to test type of firstFieldName and
// secondFieldName properties here?
}
#Override
public boolean isValid(final Object value, final ConstraintValidatorContext context) {
// omitted
}
}
Is this a sensible thing to do? What approach would you suggest I use if it is? And what action should occur if the properties are not of the correct type?
You can't really do the check in initialize() since you can't access the validated object there. Instead you could check the type of the fields of the validated object in isValid() using reflection:
if ( !Calendar.class.isAssignableFrom(
value.getClass().getField( firstFieldName ).getType() ) ) {
throw new ValidationException( "Field " + firstFieldName + " is not of type Calendar." );
}

Why do we need to set the recipient explicitly for IMessenger.Subscribe()?

Here is the singature of the Register method:
IMessanger.Register<TMsg>(object recipient, Action<TMsg> action);
Why do we need the recipient if action holds the reference in its Target property?
When the given action does not use instance members of the class where it was defined then Target is null.
But this happens quite rarely. I mean that it is not a very common way we use event handlers.
I'd like to understand why there is no additonal Register method signature with no recipient parameter? Am I missing something important?
IMessanger.Register<TMsg>(Action<TMsg> action);
You can actually register a recipient for a specific message from anywhere in your application, not just from the class that is the recipient. For example, consider the following scenario:
public class ClassA : ViewModelBase
{
public ClassA()
{
Messenger.Default.Register<SomeMessage>(this, SomeAction);
Messenger.Default.Register<SomeMessage>(ViewModelLocator.ClassB, SomeAction);
}
private void SomeAction(SomeMessage msg)
{
// do something
}
}
public class ClassB : ViewModelBase
{
public ClassB()
{
}
}
In the case of the second Registor method call, the Target property of the Action will NOT be the same as the recipient parameter. Therefore, to be consistent, it was most likely safer to always require a recipient parameter.
Of course, you are correct that this scenario is probably less common than the scenario where you simply pass this as the recipient. So in that case, if typing this becomes to burdensome for you then you could always define your own Register extension method which simply passes the Target property along to the actual Register method:
public static class MessengerHelper
{
public static void Register<TMessage>(this IMessenger messenger, Action<TMessage> action)
{
messenger.Register<TMessage>(action.Target, action);
}
}
You can then register for messages like this:
public class ClassA : ViewModelBase
{
public ClassA()
{
Messenger.Default.Register<SomeMessage>(SomeAction);
}
private void SomeAction(SomeMessage msg)
{
// do something
}
}
It is done so you can say Messenger.UnregisterRecepient(recepient); which then unsubscribes every action registered to this receiver.

Resources