I am using Javers and need to provide the author of a commit. In order to do this, I create this class
private class SimpleAuthorProvider : AuthorProvider {
override fun provide(): String {
return "the_author"
}
}
However instead of hard coding the string, I would like to use the user who has sent the request. I am using a ReactiveAuthenticationManager to set the authentication. This means I need to access it using ReactiveSecurityContextHolder.getContext() which returns a Mono. As I need to essentially return a string from this, I am not sure how to access it?
I have tried to even do a hack or two e.g. block() or toFuture().get() but these both do not work.
Are there any other suggestions?
First, if you are new to reactive programing, don't use Webflux. It's a very complex framework, which you probably don't need -- see this talk https://www.youtube.com/watch?v=5TJiTSWktLU
There is no out-of-the-box integration for Javers and Webflux. Still, Javers supports simple async programing based on CompletableFutures from Java lang. What you can do is to convert CompletableFuture returned by javers.commitAsync() to Mono which will made Webflux happy.
As a rule of thumb, never call block() on Mono in production code. You should register an action -- here javers.commitAsync() -- which will be executed when a Mono is completed using doOnSuccess() or map(), see https://www.naturalprogrammer.com/blog/16393/spring-security-get-current-user-programmatically.
Related
I am trying to design and implement a framework to communicate with server (it's an iOS framework written in Swift). The challenge I am facing is the architecture - there are two ways of communicating with the server and I have to implement both (different versions). I really want to achieve having a stateless client, with methods such as: Client.authenticate() or Client.downloadFile(). The problem is when having two implementations I would end up with methods in my Client class like this one:
public class func authenticate(state: state) {
if (state.type == 1) {
Client1.authenticate(state)
} else {
Client2.authenticate(state)
}
}
Repeated for every single method...
I wanted to initially keep the client like this - stateless and static and have only state objects that hold the actual state as there could be many connections to the server with various states. By that I wanted to avoid having the client as an object and both holding the state and performing the calls to the server. The problem is that this approach is just...dirty I guess. What would be a more DRY, readable and sustainable way of doing this?
I don't fully understand your intention without more code samples, but the patterns I will present to you will surely clear things up for you.
If your Client class always uses either Client1 or Client2 (or more specifically, if your every client object state variable doesn't change through it's instances lifetime) you should use Dependency Injection.
You create a procol (Let's call it RemoteClient with authenticate method (and every other method that the server client should implement) and make Client1 and Client2 conform to that protocol.
Now you make your Client class to accept a RemoteClient in it's constructor.
Now whatever creates the Client object, it can decide what to inject into the constructor: the Client1 concrete class object, or Client2.
There's a lot of articles about Dependency Injection so I won't cover it in much detail.
Example article
You can also use the Strategy design pattern, which is very similiar but kind of different in intent:
Strategy design pattern
Difference between DI and Strategy
EDIT
After you've clarified what you want to do in comments below:
In that case, you can use reflection/metadata and use dictionary/map to invoke the client you want.
(pseudocode)
enum ServerType
{
client1,
client2
}
Dictionary* serversDictionary; // key = ServerType , value = object of protocol type RemoteLocation
static init
{
serversDictionary[client1] = Client1.self; // using swift class metadata
serversDictionary[client2] = Client2.self; // using swift class metadata
}
static authenticate(ServerType type) {
let locationToSendAuthTo = serversDictionary[type];
locationToSendAuthTo.authenticate(type);
}
I'm not sure if Swift works that way because I've just started using it. I'm not sure if you can call a static method on a class type. The docs are pretty thin on that.
More here:
Swift class introspection & generics
I have a Dart class (foo.dart):
class Foo {
void talk() {
print('Hello');
}
}
After compiling foo.dart to JavaScript, I'd like to be able to use Foo like this:
var foo = new Foo(); // from foo.dart.js
foo.talk() // prints "Hello"
My questions:
Is this currently possible?
If so, how?
If not, what plans, if any, are in place to make it possible?
The dart:js library documentation states:
This library does not yet make Dart objects usable from JavaScript, their methods and proeprties [sic] are not accessible, though it does allow Dart functions to be passed into and called from JavaScript.
That word "yet" offers some hope, but I've found very little on this topic anywhere else.
Edit:
I do realize it's possible to call Dart functions from JavaScript using dart2js. However, what I'm trying to do is somewhat different. I'd like to be able to access all of the functionality of a Dart class from JavaScript.
Due to tree-shaking and minification this is normally not possible. If you have a Dart application (with a main() then you can make a Dart function available to be called from JavaScript (see How to call a Dart function from Javascript? for an example).
As far as I know there are plans to support your requirement but I have no idea about progress or when such a feature might be available.
This is the related project https://github.com/dart-lang/js-interop
I have something like this:
class MyClass
{
static void DoSomething(arg1, arg2){...}
}
Via reflection, I am able to get the ClassMirror of this class. From this point, how would I get to the concrete static function so I can call it.
Note that I tried to use:
ObjectMirror.invoke('DoSomething', [arg1, arg2]);
which would initially appear to work, but it doesn't support passing of complex types as arguments, This static function requires a complex type as one of it's arguments.
Ideally, I'd like to get the 'Function' object that represents the static method so I can invoke it directly.
a. The current state of affairs is temporary. The plan is that the mirror API will wrap the arguments with mirrors for you.
b. The API may eventually support a getProperty method that will give you a Future on the function object. However, you will not get a Function object directly, so this won't really make any difference in this case.
c. The core idea is that the API fundamentally works on mirrors. To make it more usable, it should accept non-mirrors as input and wrap them in mirrors for you. It will always return mirrors, and in some cases return futures on these. This is so the API works the same for remote and local cases.
d. Resources for understanding mirrors:
http://www.bracha.org/mirrors.pdf (academic paper, tough going)
http://www.hpi.uni-potsdam.de/hirschfeld/events/past/media/100105_Bracha_2010_LinguisticReflectionViaMirrors_HPI.mp4 (a video, pre-Dart, discusses earlier Mirror systems)
http://gbracha.blogspot.com/2010/03/through-looking-glass-darkly.html (an old, pre-dart, blog post of mine on mirrors)
http://www.wirfs-brock.com/allen/posts/228 (Allen Wirfs-Brock's blog. Allen was a mirror pioneer back in Smalltalk in the 90s)
http://www.wirfs-brock.com/allen/posts/245
You can also search my blog, or Allen Wirf-Brock's for posts on the topic.
When registering two handlers for the same type, but with different URIs, the handler selection algorithm doesn't seem to check the uri when it determines which handler to use.
If you run the program below, you'll notice that only HandlerOne will be invoked (twice). It does not matter if I call for "/one" or "/two", the latter supposed to be handled by HandlerTwo.
Am I doing something wrong or is this something to be fixed in OpenRasta? (I'm using 2.0.3.0 btw)
class Program
{
static void Main(string[] args)
{
using (InMemoryHost host = new InMemoryHost(new Configuration()))
{
host.ProcessRequest(new InMemoryRequest
{
HttpMethod = "GET",
Uri = new Uri("http://x/one")
});
host.ProcessRequest(new InMemoryRequest
{
HttpMethod = "GET",
Uri = new Uri("http://x/two")
});
}
}
}
class Configuration : IConfigurationSource
{
public void Configure()
{
using (OpenRastaConfiguration.Manual)
{
ResourceSpace.Has.ResourcesOfType(typeof(object))
.AtUri("/one").HandledBy(typeof(HandlerOne));
ResourceSpace.Has.ResourcesOfType(typeof(object))
.AtUri("/two").HandledBy(typeof(HandlerTwo));
}
}
}
class HandlerOne
{
public object Get() { return "returned from HandlerOne.Get"; }
}
class HandlerTwo
{
public object Get() { return "returned from HandlerTwo.Get"; }
}
Update
I have a feeling that I could accomplish what I want similar using UriNameHandlerMethodSelector as described on http://trac.caffeine-it.com/openrasta/wiki/Doc/Handlers/MethodSelection, but then I'd have to annotate each handler methods and also do AtUri().Named(), which looks like boilerplate to me and I'd like to avoid that. Isn't AtUri(X).HandledBy(Y) making the connection between X and Y clear?
Eugene,
You should never have multiple registrations like that on the same resource type, and you probably never need to have ResourcesOfType<object> ever associated with URIs, that'll completely screw with the resolution algorithms used in OpenRasta.
If you're mapping two different things, create two resource classes. Handlers and URIs are only associate by resource class, and if you fail at designing your resources OpenRasta will not be able to match the two, and this is by design.
If you want to persist down that route, and I really don't think you should, then you can register various URIs to have a name, and hint on each of your methods that the name ought to be handled using HttpOperation(ForUriName=blah). That piece of functionality is only there for those very, very rare scenarios where you do need to opt-out of the automatic method resolution.
Finally, as OpenRasta is a compsable framework, you shouldnt have to go and hack around existing classes, you ought to plug yourself into the framework to ensure you override the components you don't want and replace them by things you code yourself. In this case, you could simply write a contributor that replaces the handler selection with your own moel if you don't like the defaults and want an MVC-style selection system. Alternatively, if you want certain methods to be selected rather than others, you can remove the existing operation selectors and replace them (or complement them with) your own. That way you will rely on published APIs to extend OpenRasta and your code won't be broken in the future. I can't give that guarantee if you forked and hacked existing code.
As Seb explained, when you register multiple handlers with the same resource type OpenRasta treats the handlers as one large concatenated class. It therefore guesses (best way to describe it) which potential GET (or other HTTP verb) method to execute, which ever it thinks is most appropriate. This isn't going to be acceptable from the developers prospective and must be resolved.
I have in my use of OpenRasta needed to be able to register the same resource type with multiple handlers. When retrieving data from a well normalised relational database you are bound to get the same type response from multiple requests. This happens when creating multiple queries (in Linq) to retrieve data from either side of the one-to-many relation, which of course is important to the whole structure of the database.
Taking advice from Seb, and hoping I've implemented his suggestion correctly, I have taken the database model class, and built a derived class from it in a resources namespace for each instance of when a duplicating resource type might have been introduced.
ResourceSpace.Has.ResourcesOfType<IList<Client>>()
.AtUri("/clients").And
.AtUri("/client/{clientid}").HandledBy<ClientsHandler>().AsJsonDataContract();
ResourceSpace.Has.ResourcesOfType<IList<AgencyClient>>()
.AtUri("/agencyclients").And
.AtUri("/agencyclients/{agencyid}").HandledBy<AgencyClientsHandler>().AsJsonDataContract();
Client is my Model class which I have then derived AgencyClient from.
namespace ProductName.Resources
{
public class AgencyClient: Client { }
}
You don't even need to cast the base class received from your Linq-SQL data access layer into your derived class. The Linq cast method isn't intended for that kind of thing anyway, and although this code will compile it is WRONG and you will receive a runtime exception 'LINQ to Entities only supports casting Entity Data Model primitive types.'
Context.Set<Client>().Cast<AgencyClient>().ToList(); //will receive a runtime error
More conventional casts like (AgencyClient) won't work as conversion to a SubClass isn't easily possible in C#. Convert base class to derived class
Using the AS operator will again compile and will even run, but will give a null value in the returned lists and therefore won't retrieve the data intended.
Context.Set<Client>().ToList() as IEnumerable<AgencyClient>; //will compile and run but will return null
I still don't understand how OpenRasta handles the differing return class from the handler to the ResourceType but it does, so let's take advantage of it. Perhaps Seb might be able to elaborate?
OpenRasta therefore treats these classes separately and the right handler methods are executed for the URIs.
I patched OpenRasta to make it work. These are the files I touched:
OpenRasta/Configuration/MetaModel/Handlers/HandlerMetaModelHandler.cs
OpenRasta/Handlers/HandlerRepository.cs
OpenRasta/Handlers/IHandlerRepository.cs
OpenRasta/Pipeline/Contributors/HandlerResolverContributor.cs
The main change is that now the handler repository gets the registered URIs in the initializing call to AddResourceHandler, so when GetHandlerTypesFor is called later on during handler selection, it can also check the URI. Interface-wise, I changed this:
public interface IHandlerRepository
{
void AddResourceHandler(object resourceKey, IType handlerType);
IEnumerable<IType> GetHandlerTypesFor(object resourceKey);
to that:
public interface IHandlerRepository
{
void AddResourceHandler(object resourceKey, IList<UriModel> resourceUris, IType handlerType);
IEnumerable<IType> GetHandlerTypesFor(object resourceKey, UriRegistration selectedResource);
I'll omit the implementation for brevity.
This change also means that OpenRasta won't waste time on further checking of handlers (their method signatures etc.) that are not relevant to the request at hand.
I'd still like to get other opinions on this issue, if possible. Maybe I just missed something.
Please be gentle, I'm a newb to this IoC/MVC thing but I am trying. I understand the value of DI for testing purposes and how IoC resolves dependencies at run-time and have been through several examples that make sense for your standard CRUD operations...
I'm starting a new project and cannot come up with a clean way to accomplish user permissions. My website is mostly secured with any pages with functionality (except signup, FAQ, about us, etc) behind a login. I have a custom identity that has several extra properties which control access to data... So....
Using Ninject, I've bound a concrete type* to a method (Bind<MyIdentity>().ToMethod(c => MyIdentity.GetIdentity()); so that when I add MyIdentity to a constructor, it is injected based on the results of the method call.
That all works well. Is it appropriate to (from the GetIdentity() method) directly query the request cookies object (via FormsAuthentication)? In testing the controllers, I can pass in an identity, but the GetIdentity() method will be essentially untestable...
Also, in the GetIdentity() method, I will query the database. Should I manually create a concrete instance of a repository?
Or is there a better way all together?
I think you are reasonably on the right track, since you abstracted away database communication and ASP.NET dependencies from your unit tests. Don't worry that you can't test everything in your tests. There will always be lines of code in your application that are untestable. The GetIdentity is a good example. Somewhere in your application you need to communicate with framework specific API and this code can not be covered by your unit tests.
There might still be room for improvement though. While an untested GetIdentity isn't a problem, the fact that it is actually callable by the application. It just hangs there, waiting for someone to accidentally call it. So why not abstract the creation of identities. For instance, create an abstract factory that knows how to get the right identity for the current context. You can inject this factory, instead of injecting the identity itself. This allows you to have an implementation defined near the application's composition root and outside reach of the rest of the application. Besides that, the code communicates more clearly what is happening. Nobody has to ask "which identity do I actually get?", because it will be clear by the method on the factory they call.
Here's an example:
public interface IIdentityProvider
{
// Bit verbose, but veeeery clear,
// but pick another name if you like,
MyIdentity GetIdentityForCurrentUser();
}
In your composition root you can have an implementation of this:
private sealed class AspNetIdentityProvider : IIdentityProvider
{
public MyIdentity GetIdentityForCurrentUser()
{
// here the code of the MyIdentity.GetIdentity() method.
}
}
As a trick I sometimes have my test objects implement both the factory and product, just for convenience during unit tesing. For instance:
private sealed class FakeMyIdentity
: FakeMyIdentity, IIdentityProvider
{
public MyIdentity GetIdentityForCurrentUser()
{
// just returning itself.
return this;
}
}
This way you can just inject a FakeMyIdentity in a constructor that expects an IIdentityProvider. I found out that this doesn’t sacrifice readability of the tests (which is important).
Of course you want to have as little code as possible in the AspNetIdentityProvider, because you can't test it (automatically). Also make sure that your MyIdentity class doesn't have any dependency on any framework specific parts. If so you need to abstract that as well.
I hope this makes sense.
There are two things I'd kinda do differently here...
I'd use a custom IPrincipal object with all the properties required for your authentication needs. Then I'd use that in conjunction with custom cookie creation and the AuthenticateRequest event to avoid database calls on every request.
If my IPrincipal / Identity was required inside another class, I'd pass it as a method parameter rather than have it as a dependency on the class it's self.
When going down this route I use custom model binders so they are then parameters to my actions rather than magically appearing inside my action methods.
NOTE: This is just the way I've been doing things, so take with a grain of salt.
Sorry, this probably throws up more questions than answers. Feel free to ask more questions about my approach.