When I have Spring Security disabled, Swagger2 (springfox 2.5) seems to work fine, but when I enable it again, the JSON it produces when calling http://localhost:8082/v2/api-docs seems to have some kind of problem. Taking a look at the browser console I find:
TypeError: e.schema is undefined
Comparing both api-docs, the one produced with Spring Security on is much longer. I have done all that says here. It was really helpful for being able to reach Swagger with Spring Security on, but it seems not to be enough. Why are these JSON so different? Why the one with Spring Security on seems to lack some info?
We have also used below paths in our spring security config and it was enough:
"/v2/api-docs", "/configuration/ui", "/swagger-resources", "/configuration/security", "/swagger-ui.html", "/webjars/**"
Could you show some code?
What kind of JSON converter do you use? Gson, Jackson?
Do you have some spring/spring security configuration in xml files?
Related
I am using graphql-spqr-spring-boot-starter, version 0.0.5 in my spring boot application.
#GraphQLApi & #GraphQLQuery working fine and I am fetching data on /gui as well.
But as many have faced I am trying to apply the authentication part on graphql server calls. I am using JWT token in my application for REST API authorization/authentication.
So I have token which I suppose can be used for validation here as well.
I have tried using:
#PreAuthorize("hasRole('ROLE_RECRUITER_HR')")
but it gives compile time error:
io.leangen.graphql.metadata.exceptions.TypeMappingException: The
registered object of type com.sun.proxy.$Proxy90 appears to be a
dynamically generated proxy
For these and other possible issues, is it better to use wrapper graphql library like spring-boot-starter or it is safer to use graphql-spqr which more steps in my hand.
EDIT: GraphQL SPQR Spring Boot starter v0.0.6 fixed the issue and should work out of the box.
This is a bug in the starter. It doesn't properly detect the types when JDK proxies (and not CGLib) are used. I will make sure to fix this for the next release.
There's a couple of ways to temporarily work around this, but none of them are nice unfortunately.
You could e.g. force Spring to use CGLIB by e.g.
#EnableAspectJAutoProxy(proxyTargetClass = true)
but this has potentially wide implications so I would recommend you simply wait a bit. I'll release a new version with a fix in a couple of days, as this is a very important bug.
I am using a org.springframework.security.ldap.authentication.LdapAuthenticationProvider.LdapAuthenticationProvider(LdapAuthenticator authenticator, LdapAuthoritiesPopulator authoritiesPopulator) to validate my clients. When I am calling from SoapUI I can see this pointcut being executed every time execution(Authentication org.springframework.security.authentication.ProviderManager.authenticate(Authentication)) When I call from postman, it only gets executed the first time postman calls.
It appears that somehow my app is caching the client and saying it does not need re-authenticated when I call from postman, but this is not happening when I call from soapui. What is the difference?
I have tried changing all settings I can see in postman and soapui, but I cannot seems to make any difference in the results. Can someone describe, or point me to a resource that describes what is going on?
Seems to be related to cookies... In postman I found a property, disable cookie jar. If that is enabled i get the same performance as soapui and it always validates. I guess now I need to see how cookies work with spring security.
I want to enable session for every user who requests for the token using the URL "/auth/local" which is the default API provided by Strapi. I guess Strapi is by default configured with Koa session but inspite of that no session cookie is returned in response by default.
What is the best way to enable session management in Strapi? Can anyone share their experience on this one ?
Why do not you try using the mechanism of sessionStrage.
I referred to this page of the official reference.
(I used non-react part because I do not use it)
Plugin Development - Front-end Helpers - Auth
https://strapi.io/documentation/plugin-development/utils.html#auth
github
https://github.com/strapi/strapi-examples/tree/master/login-react/react-login-front-end-app
blog?
https://medium.com/strapi/protected-routes-and-authentication-with-react-and-node-js-d31d234644cd
The source of auth.js is pretty helpful
https://github.com/strapi/strapi-examples/blob/master/login-react/react-login-front-end-app/app/utils/auth.js
I POST from the request module and returned to json
auth.setToken (body.jwt, body.rememberMe)
auth.setUserInfo (body.user, body.rememberMe)
Then we kept the data in sessionStrage.
I do not know if it will be helpful, but maybe it may be useful, so I wrote it.
I am a Japanese who is not good at English, so I'm going to google translate as it is.
Even if there is a strange part, I do not know, so please forgive that point.
We have a couple of web applications written on Java Spring, we are using spring-data-redis and #EnableRedisHttpSession. I was wondering what are the spring session internals. Would it check redis database for duplicate session keys before creating a new session?
I looked at spring documentation and also did a google search but couldn't get a definitive answer.
Found the solution after going through spring session project's github issues. Answer provided by #Avnish doesn't work because in cluster configuration redis does not provide databases, there is just a single database 0 and SELECT commands are not supported.
spring-session#1.1.0.RELEASE solves this issue by providing session namespaces. If you are using #EnableRedisHttpSession annotation, you can add redisNamespace property to it. Or you can add the key in spring.session.redis.namespace property in your .properties or .yml file.
As far as as spring-session is concerned, it'll assume that another application is part of the cluster and will try to reuse existing session if found for given id, although very unlikely that two different applications will generate same session ids considering it's generated via random UUID. Following are the options that you can go with to safe guard yourself anyway.
If you are using spring boot, use different value of spring.redis.database property for each of your application (details here, search for "# REDIS")
If you are using spring-data-redis directly then you should be setting this value directly in the JedisConnectionFactory bean that you are using in your application. For XML configuration, following would do:
<bean id="jedisConnectionFactory"
class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
<property name="database" value="1" />
</beans>
Hope it helps!!
When using PayloadRootAnnotationMethodEndpointMapping together with WS-Security Encryption, I get this error: [EndpointNotFound] No endpoint mapping found for [SaajSoapMessage {http://www.w3.org/2001/04/xmlenc#}EncryptedData]
Spring WS wants first finding the right Endpoint, and only later decrypts the SOAP body. This is obviously not the right thing to do.
Please dont tell me that the SoapActionAnnotationMethodEndpointMapping is the solution. Is not there a better way? I would not like routing based on SOAP Action or WS-A Action.
Unfortunately, using the SoapActionAnnotationMethodEndpointMapping or AnnotationActionEndpointMapping are the only provided mappings you can use. In Spring-WS, the EndpointMapping is queried before any of the interceptors are invoked - including the security interceptor, and such you have to find a mapping that does not depend on the encrypted message payload.
That said, since EndpointMapping is an interface, you can also write your own, and include any kind of routing logic you can think of. Extending from AbstractAnnotationMethodEndpointMapping is a good start for this approach. When your mapping is done, just wire it up in the application context and it should be detected automatically by Spring-WS's MessageDispatcher.