Does anyone know how to override the header name 'X-Auth-Token'?
We are using it mostly for session management (not auth) and want to give it a different name. Can't find anything online about this.
In your configuration add a HeaderHttpSessionIdResolver type bean.
#Bean
public HeaderHttpSessionIdResolver httpSessionIdResolver() {
return new HeaderHttpSessionIdResolver("Your-Header-Name-Here");
}
and it should automatically pick that up and use it.
Related
I have a Spring Boot project with webapp folder like:
webapp\
myapp\
api\
dashboard.xhtml
auth\
login.xhtml
register.xthml
When I run the sever I need to always enter the url http://localhost:8080/myapp/auth/login.xhtml to begin.
I found this very annoying and want to automatically redirect to this url when I enter just http://localhost:8080.
How can I achieve this?
You can make a new configuration inheriting the WebMvcConfigurer class.
In Spring Boot, the MVC part is measuring automatically, so you wouldn't do any more request controlling part in case you are new to it.
The WebMvcConfigurer class offers addViewControllers virtual function, so that you can override it and add your own controller inside it.
Just like:
#Override
public void addViewControllers(ViewControllerRegistry registry) {
registry.addViewController("/")
.setViewName("forward:/helloworld.xhtml");
registry.setOrder(Ordered.HIGHEST_PRECEDENCE);
}
For more detailed part, you can find it here.
Delete an article using DELETE /articles/:id
Delete all articles using DELETE /articles/
How can I make deletion support available only in dev environment and prevent it for test, staging, production environments in spring boot
First thing that comes to my mind would be adding a DeletionController which is created either based on a property or, in your case, on the active profile.
Something like:
#Profile("dev")
#RestController
public class DeletionController {
#DeleteMapping("articles")
public void deleteAll() {
//delete all articles
}
#DeleteMapping("articles/{id}")
public void delete(#PathVariable Integer id) {
//delete article for given id
}
}
Doing so Spring will only instantiate the DeletionController when the dev profile is active making the related endpoints available only in that case. You also have the possibility to have it active/inactive with more complex conditions like #Profile("dev & staging") or #Profile("dev & !production"). You can control the active profiles in your property file with the property spring.profiles.active.
The property approach would be using, instead of #Profile, the annotation #ConditionalOnProperty properly configured.
I have a java app written by a developer. The app is using Spring Security and uses static usernames and passwords. I'm trying to find where the usernames are stored so that I can add new users and remove old ones.
I'm using Eclipse IDE to view the source code. Any help is much appreciated.
Thanks
Search after a class that extends WebSecurityConfigurerAdapter (so basically search after this string in code). Look over the file you have found. Either there are your credentials directly, or post the content you find there.
In spring-security chances of having static user credentials are:
In application property file
spring.security.user.name=
spring.security.user.password=
In configure method of WebSecurityConfigurerAdapter extended class:
#Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
auth.inMemoryAuthentication()
.withUser("USERNAME")
.password("USERPASSWORD");
}
this are two ways of creating static users.
We are currently developing an application intended for deployment on a WebSphere server. The application should use an in-house Service Provider, that provides access to services implemented as remote EJBs. The Service Provider bean has some hard-coded jndi-names to use.
Now during development we are using Tomee and in general all is working nicely. All except one thing:
The ServiceProvider does a jndi-lookup of "cell/persistent/configService". Now I tried to create a mock ear that contains mock EJBs for these services. I am able to deploy them, and I am able to access them from the application using jndi-names like: "java:global/framework-mock-ear-1.0.0-SNAPSHOT/framework-mock-impl/ConfigServiceMock" but it seems to be impossible to access them using a jndi lookup of: "cell/persistent/configService" ... now I added an openejb-jar.xml file to my mock implementation containing:
<openejb-jar>
<ejb-deployment ejb-name="ConfigServiceMock">
<jndi name="cell/persistent/configService"
interface="de.thecompany.common.services.config.ConfigService"/>
</ejb-deployment>
</openejb-jar>
And I can see during startup, that the bean seems to be registered correctly under that name:
INFORMATION: Jndi(name=cell/persistent/configService) --> Ejb(deployment-id=ConfigServiceMock)
But I have now idea how to make the other ear be able to access this bean using that name.
The Service Provider part is given and we are not able to change this at all, so please don't suggest to change the hard-coded jndi names. We surely would like to do so, but are not able to change anything.
Ok ... to I wasted quite some time on this. Until I finally came up with a solution. Instead of configuring Tomee and OpenEJB to find my beans, I hijacked the InitialContext and rewrote my queries.
package de.mycompany.mock.tomee;
import org.apache.naming.java.javaURLContextFactory;
import javax.naming.Context;
import javax.naming.NamingException;
import java.util.Hashtable;
public class MycompanyNamingContextFactory extends javaURLContextFactory {
private static Context initialContext;
#Override
public Context getInitialContext(Hashtable environment) throws NamingException {
if(initialContext == null) {
Hashtable childEnv = (Hashtable) environment.clone();
childEnv.put("java.naming.factory.initial", "org.apache.naming.java.javaURLContextFactory");
initialContext = new MycompanyInitialContext(childEnv);
}
return initialContext;
}
}
By setting the system property
java.naming.factory.initial=de.mycompany.mock.tomee.MycompanyNamingContextFactory
I was able to inject my MycompanyInitialContext context implementation:
package de.mycompany.mock.tomee;
import org.apache.openejb.core.ivm.naming.IvmContext;
import org.apache.openejb.core.ivm.naming.NameNode;
import javax.naming.NamingException;
import java.util.Hashtable;
public class MycomanyInitialContext extends IvmContext {
public MycomanyInitialContext(Hashtable<String, Object> environment) throws NamingException {
super(environment);
}
#Override
public Object lookup(String compositName) throws NamingException {
if("cell/persistent/configService".equals(compositName)) {
return super.lookup("java:global/mycompany-mock-ear-1.0.0-SNAPSHOT/mycompany-mock-impl/ConfigServiceMock");
}
if("cell/persistent/authorizationService".equals(compositName)) {
Object obj = super.lookup("java:global/mycompany-mock-ear-1.0.0-SNAPSHOT/mycompany-mock-impl/AuthServiceMock");
return obj;
}
return super.lookup(compositName);
}
}
I know this is not pretty and if anyone has an idea how do make this easier and prettier, I'm all ears and this solution seems to work. As it's only intended on simulating production services during development, this hack doesn't induce any nightmares for me. Just thought I'd post it, just in case someone else stumbles over something similar.
I know this answer is coming a few years after the question, but a simpler solution would be to simply set the system property as follows (say in catalina.properties):
java.naming.initial.factory=org.apache.openejb.core.OpenEJBInitialContextFactory
This allows you to lookup the ejb by the name you set, and the one that shows in tomee logs during startup, eg your 'cell/persistent/configService' from
INFORMATION: Jndi(name=cell/persistent/configService) --> Ejb(deployment-id=ConfigServiceMock)
With the system property set you can lookup the ejb the way you would want
final Context ctx = new InitialContext();
ctx.lookup("cell/persistent/configService")
The OpenEJBInitialContextFactory allows access to local EJBs as well as container resources.
If you didn't want to set the system property (as it would affect all applications in the tomee) you could still use the factory setting it the 'standard' way:
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.core.OpenEJBInitialContextFactory");
final Context ctx = new InitialContext(properties);
ctx.lookup("cell/persistent/configService");
And of course you could still look them up using the global "java:global/" as well with that factory.
I have a JIRA plugin that I'm developing that has a REST service. That service should be able to accept POSTed requests, unmarshall some data and store it. The seemingly suggested way to do this in JIRA is to make use of the Bandana persistence framework. According to this page, I should be able to simply define a setter that Spring should call to give me my Bandana manager.
#Path("/path")
public class SCMService {
private BandanaManager bandanaManager;
// setter called by Spring
public void setBandanaManager(BandanaManager bandanaManager) {
this.bandanaManager = bandanaManager;
}
//...More methods...
}
However, when I test this, the setter is never being called and my manager is null. I'm guessing this should be as simple as registering this service with Spring for injection somehow but I can't seem to find anything like that.
How would I get my setter called? Is there a better way to do this?
Er, I'm not sure that JIRA uses Bandana in that way, though Confluence does. You can certainly post data to a JIRA rest resource and then store it using properties tables
Something like this:
#POST
#Consumes (MediaType.APPLICATION_XML)
public Response createComponentAndIssues(#Context HttpServletRequest request, ...