I am starting to develop a GWT application in MVP style (GWTP) and which uses Spring security for authentication and authorization on server side.
In many views of the application, I have to enable or disable controls with respect to a granted authority of the current user. I already have an RPC service which provides access to a userDetailsDto containing all the necessary information.
Now my question: What is the best place to store the user DTO on client side?
Since the user rights are relevant in many presenters, I would have to pass it around everywhere. Alternatively, I could set an RPC service instance in every presenter and requets the user details each time (probably cached on client-side). But i don't like the idea of having a user RPC service in each presenter just for this purpose.
To be honest, I'd rather would prefer a central registry where to put the UserDetails object and which is accessable from anywhere in my app. Is there already such a registry in GWT?
As in my example, you might often be confronted with horizontally used objects. How to deal with them in GWT?
Simply store your current user in public static variable.
It will be accessible from everywhere.
I inject an "AppState" object into all of the presenters that need to know things like the rights of the user logged in, their preferences, etc. I prefer injection to a public static variable because it feels more controlled, is easier to mock up in tests, and the extra typing forces me to consider whether each object really needs access to the global data.
Related
Imagine I have a Razor Page or such like. Imagine the data used by that Razor Page is not used by any other page at all. So the data retrieval is very specific to this page only.
Is it bad practice to just grab the data directly using a database connection from within that Razor Page local to the only place that data is to be used?
If so, why should I abstract the data away into a separate API that isn't re-used anywhere? Why is it good practice?
It seems to me, that REST APIs are sometimes used unnecessarily and for no good reason. As if because every example video shows data retrieval from REST APIs. Correct me if I am wrong.
If your application is purely a server-side app, there is no justification for creating RESTful API that serves up JSON for it. Those kinds of APIs are usually created for "external" consumers, by which I mean third parties or the browser (via JavaScript). They are commonly implemented for client side apps - single page apps typically like React, Angular or Blazor where JSON is the data format of choice for the browser.
As to whether you should open database connections in your PageModel class, that's another question. For simple apps, why not? But for apps that need unit testing, it's not a good idea. You will be unable to execute unit test against the PageModel class without hitting the database.
As a habit, I tend to put the code that connects to a database in a series of separate classes, each one having an interface, and then inject them into the PageModel via dependency injection. That way I can mock the service represented by the interface for unit testing.
You might want to implement services that generate data as JSON within a Razor Pages app if you have some functionality that depends on Ajax requests for data. For those, you could use Web API controllers, minimal request handlers or even named handler methods that return JsonResult objects in the PageModel classes. With all of those, you might still want to put the code that actually calls the database in a separate class that is injected into the handler.
I would like to have access to the current user somewhere deep in my models of my Play app, for things like setting the author, checking that the user can actually save this type, etc.
Ideally, what I would like to use is Guice's #RequestScoped to inject the same UserIdentity across my request, wherever I need it. However, as far as I can tell, the Play! Framework only supports #Singleton and no-scope. So either we'd get the same UserIdentity injected across requests or a different one for every model/util we requested. Both are no-gos for obvious reasons.
Is there some way to utilise this behaviour in Play 2.5?
Other things I have tried
I've tried using a combination of Play's session and cache. But the problem I have is that session is immutable, so I can't add anything to it to reuse in that same request.
I've looked at a bunch of auth frameworks but they all seem to focus on securing actions, not providing me with a current User object.
Check out my answer to a question on redirecting requests, where I given an example of getting the current user in each request.
In this case the authorization key is handed out on login and the client passes it in on every request thereafter.
Well first i would like to mention about the architecture a little bit.
We have a UI application that uses a REST api for all the operations and use cases. UI application uses credentials to call REST api, since there are other non-UI application consuming same services.
We do authentication and authorization on REST api application using Spring Security. In fact whole application uses Spring portfolio from top to bottom.
For authentication and authorization of operations on UI application we also use Spring Security. We protect urls and display the currently logged in user only the operations that he is authorized to do.
Here is the new requirement: Some logged in users see a resource with restrictions. That mean same resource is shown with fewer fields or fewer updatable fields.
Exploring around, we narrowed down to two methods:
Use different representation for each restricted access. Based on some HTTP header set and known by client.
Use different resources for each restricted access.
If the resource-representation combinations are too much, different resource object may be less maintainable. An automated HTTP-header based restrictor aspect can be implemented. Also client have provide some header and this add minor complexity to the client.
If combinations are not too much, a new resource is created for each restricted access. Client have to call the right one at the right time. This approach can reveal hidden domain concepts as new resources and design may look more clean.
What are your thoughts? Which approach would you take?
From your architecture, I am guessing that you have the security filters setup already (I believe it's called OncePerRequestFilter in Spring?). The way I have approached this in the past is use my security filters to get the "Role" of the client (assuming you can have roles assigned for each client which map to specific permissions/restrictions on each resource object). Now based on the "Role" I have custom JSON serializer/deserializer strategies (I used GSON for this inclusion/exclusion type adapters. You can read more here (Gson custom seralizer for one variable (of many) in an object using TypeAdapter) ) that will take care of what resource fields should/should not be populated/serialized. This way, you will continue to use the same resource object and TypeAdapter for each resource object which will determine the serialization/deserialization of the resource object based on the role of the client.
One more idea that comes to my mind is method interceptors (Spring AOP). Although I have never tried it with method interceptors, I think it should still work in the sense that you will intercept the method right BEFORE it returns (and after the business logic is done) and look at the role of the client making the request. Based on that role, you can determine what fields to null out (most serializers (atleast gson) do not serialize null fields) and not serialize, before converting it to json (or whatever your return type might be) and sending it over to the client
I hope this helps.
I have a concern where I am writing a custom membership provider, but I'm not sure where to put it. I don't really have any code to show you, but basically the provider needs access to System.Web.Security in order to inherit the class, but it also needs data access (i.e. a connection string + LINQ to SQL) to do simple tasks such as ValidateUser.
How can I write a membership provider that adheres to the principles of DDD that I've read about in Pro ASP.NET MVC2 Framework by Apress? My one thought was to write another class in my domain project which does all the "work" related to database stuff. In essence I would have double the number of methods. Also, can this work with dependency injection (IoC)?
Hope this isn't too general ...
Look forward to the hive-mind's responses!
Edit: I just noticed in a default MVC2 project there is an AccountController which has a wrapper around an IMembershipService. Is this where my answer lies? The AccountController seems to have no database access component to it.
Asp.net user management features are super invasive.
They even spam database with profile tables and what not.
When I had to implement users management of my application, I successfully avoided all that mess and still was able to use asp.net in-built roles, user identities etc. Moving away from all that though cause my domain is getting smart enough to decide what can be seen and done so it makes no sense to duplicate that in UI client.
So... yeah. Still have zero problems with this approach. Haven't changed anything for ~4 months.
Works like a charm.
I see a lot of articles and posts on how to create a custom MembershipProvider, but haven't found any explanation as to why I must/should use it in my MVC2 web app. Apart from "Hey, security is hard!", what are critical parts of the whole MembershipProvider subsystem that I should know about that I don't, because I've only read about how to override parts of it? Is there some "behind the scenes magic" that I don't see and will have to implement myself? Is there some attribute or other piece of functionality that will trip over itself without a properly setup MembershipProvider?
I am building a web app, using a DDD approach, so the way I see it, I have a User entity and a Group entity. I don't need to customize ValidateUser() under the provider; I can just have it as a method on my User entity. I have to have a User object anyways, to implement things not under the MemebrshipProvider?
So, what gives? :)
No, you don't need it. I have sites that use it and sites that don't. One reason to use it is that plumbing is already there for it in ASP.NET and you can easily implement authentication by simply providing the proper configuration items (and setting up the DB or AD or whatever).
A RoleProvider, on the other hand, comes in very handy when using the built-in AuthorizeAttributes and derivatives. Implementing a RoleProvider will save you a fair amount of custom programming on the authorization side.