Hello first things first: Im using play framework 2.2.3 for java.
Basic tutorial about authentication in play shows how to use Annotation Security.Authenticated. The problem is that whole my application (besides login and registry forms) needs to be secured.
Now I thought of overloading GlobalSettings onRequest method and include my authentication inside, so every single call of an action would perform authentication check.
But I was told its not elegant way and was told to create another annotation similar to Security.Authenticated, but working on a whole class instead of method, and put it into my custom abstract controller class, so all my controllers that extends it will inherit this annotation.
Now I'm wondering how to make this annotation. Any tips ? Where should I start ? I know basics, how to code annotation itself, but i dont know where is right place to get annotations of controllers class to check if it contains my custom annotation, and perform authentication if so.
If you're looking for an authorization + authentication plugin for Play that can secure the whole class, and hence all the action methods within it, try SecureSocial. It has its own set of annotations, and securing every action method in a class is as easy as doing:
#SecureSocial.SecuredAction
public class MyController extends Controller {
Yes it's a little bit more work than intercepting the request and doing your check there, but its a more flexible method in case you'd like to "unsecure" some of the actions later on.
Related
I'm currently using DataFetcher for GraphQL-Java in Springboot based on the tutorial here. This works well, but I'm looking for another way to get the endpoints without implementing DataFetchers, as it seems like extra work where I have to (1) implement the resolver method, then (2) create a separate method for the corresponding DataFetcher. Is there another way to consolidate this to expose my GraphQL API a la some form of Rest controller? I have looked around quite a bit but haven't found any workable solution. Preferably (not sure if it's related) there would be a better way of annotating the endpoint as well (currently provided in the linked example with RuntimeWiring, which I'm hoping to remove as well).
In short, I would like, in Springboot, to not need for RuntimeWiring and DataFetcher (primarily this so as to remove double code for the same method and improve maintainability), and instead have another way to configure the global REST controller for my GraphQL-Java code, while also having another way to annotate the endpoint (maybe some annotator on top of the implemented methods).
Thanks!
Managed to fix it by using graphql.kick.start.tools' SchemaParser and GraphQLResolver as follows:
return SchemaParser.newParser()
.files(schemaFiles)
.scalars(scalars)
.resolvers(resolvers)
.dictionary(typeDictionary)
.build()
.makeExecutableSchema();
where the resolvers were implemented using this amazing plugin as codegen.
In this blog post, the subject of creating a new Webflowconfigurer to extend the web flow is covered.
In the examples provided this is done through classes that extend the AbstractCasWebflowConfigurer and introducing new actions that are appended to the webflow through the included process.
Is extending already existing configurers like for instance AcceptableUsagePolicyWebflowConfigurer and overriding some of its methods feasible or is that outside the scope of CAS web flow? If its feasible, what is the correct way to do this?
p.s. currently on version 5.3.x
Is extending already existing configurers like for instance AcceptableUsagePolicyWebflowConfigurer and overriding some of its methods feasible or is that outside the scope of CAS web flow?
Yes, that is feasible.
If you examine this block, you will find that AcceptableUsagePolicyWebflowConfigurer is only created conditionally, if an existing bean is not already found in the context by the same name. So to provide your own, you just need to register a bean with the same name using your own #Configuration class. Something like this:
#Bean
#DependsOn("defaultWebflowConfigurer")
public CasWebflowConfigurer acceptableUsagePolicyWebflowConfigurer() {
return new MyAcceptableUsagePolicyWebflowConfigurer(...);
}
public class MyAcceptableUsagePolicyWebflowConfigurer extends
AcceptableUsagePolicyWebflowConfigurer {}
To learn about how #Configuration classes work in general, you can:
Review this post
or This post
or consult the documentation for Spring and/or Spring Boot.
Is there an example of extending the cas login webflow using Java for cas 6.x. I assume this can be done without having to modify the login-webflow.xml.
https://apereo.github.io/cas/6.1.x/webflow/Webflow-Customization-Extensions.html does not explain very well where these changes need to be made at.
To explain the use case in as few words as possible, we have a set of controllers (and associated services) that we want to deprecate. In this same project we have introduced fancy new stuff to take its place. For the simplicity sake, all the same REST endpoints are implemented by both sets of work. The only difference being the first set of controllers are namespaced to /v1/ and the latter /v2/.
To verify that all this new work actually works in production, the goal was to incrementally push traffic in that direction. Whether it is "make 5% of the traffic go to the new stuff" or "for all calls dealing with orders from Factory X go to the new stuff" or some other piece of routing logic.
I'm trying not to touch the old code (that would require retesting all of it), so figured I could just hijack how Spring maps a request to a controller. Initially I thought I could I extend RequestMappingHandlerMapping and override the lookupHandlerMethod() call, but while that method is protected in the Abstract base class the very important map of handlerMethods and urlMap are private: leaving me in the lurch when it comes to providing a differing but existing handlerMethod.
I'd like to leverage as much as I can from the AbstractHandlerMethodMapping and the RequestMappingHandlerMapping classes. Currently, without access to the handler maps, I'm debating whether to completely use them, but change the lookupPath string and create my own HttpServerRequest class where I've edited the request URI to match my "new" controllers.
Any ideas? I'm hoping there is something I am missing.
In play framework 2, the zentasks sample shows how to do basic authentication. They subclassed Security.Authenticator and added additional methods for authorization. I find it a bit messy, since each method needs to be wrapped with an if-statement.
How can I convert the methods isOwnerOf and isMemberOf into Actions? This would allow me to simply annotate the methods. Currently, I am struggling in create an annotation that would accept the param of the method. Even if I annotate the parameter, then I do not know how to fetch it when the Action is called.
If there's a better way, I would be glad to hear so.
Take a ready to use full stack for authentication/authorization - Play Authenticate
it includes Deadbolt
it offers common providers like Facebook, Twitter, Goolge, etc
it offers common password + own providers
it supports multilanguage (also in informational mails)
it includes ready-to-use Java sample
Currently, each web service for our application has a user parameter that is added for every method. For example:
#WebService
public interface FooWebService {
#WebMethod
public Foo getFoo(#WebParam(name="alwaysHere",header=true,partName="alwaysHere") String user, #WebParam(name="fooId") Long fooId);
#WebMethod
public Result deletetFoo(#WebParam(name="alwaysHere",header=true,partName="alwaysHere") String user, #WebParam(name="fooId") Long fooId);
// ...
}
There could be twenty methods in a service, each with the first parameter as user. And there could be twenty web services.
We don't actually use the 'user' argument in the implementations - in fact, I don't know why it's there - but I wasn't involved in the design, and the person that put it there had a reason (I hope).
Anyway, I'm trying to straighten out this Big Ball of Mud.
I have already come a long way by wrapping the web services by a Spring proxy, which allows me to do some before-and-after processing in an interceptor (before there were at least 20 lines of copy-pasted boiler plate per method).
I'm wondering if there's some kind of "message header" I can apply to the method or package and that can be accessed by some type of handler or something outside of each web service method.
Thanks in advance for the advice,
LES
Who or what is expecting the user message to be bound to SOAP headers? Are your web services secured? Is that some kind of authentication header? It might have been the original intention. Actually, someone should have the answer to these questions. Find who. And if you find out that you won't ever need it, stop passing it. But if you need it, I think it's better to add it (even if you don't use it for now) unless if modifying the WSDL is not an issue (especially on the client side).
PS: I don't know how to avoid adding a parameter with #WebParam(header=true) to Java methods in order to generate a WSDL with operations having a <soap:header> in their input. AFAIK, this is how JAX-WS works when starting from Java.
If there is no reason why you need to have that variable as a parameter, you can have each one of your services extend a super class. In that super class have spring inject the MessageContext, ServletContext, ServletRequest, HttpHeaders or whichever is appropriate (probably MessageContext for JAXWS) using either the #Context annotation or #Resource annotation.
Then supply some methods in that super class to pull the user information from the request.
If authentication is what you are trying to accomplish you can manipulate contexts from predefined handlers such as protocol or Logical Handlers. E.g. implement SoapHanlder(which is a protocol handler) interface , from there add that class to the handler chain of each service you offer. Very simple and powerful. This gentleman has the best tutorial out there on this topic.