A common cross-domain problem, accidentally brought three large BUG

This article comes from the public number: Java Geek Technology Author: Duck Blood Fans

Hello hello everyone, I am a powder, recently to do a before and after separation project, every day in addition to the front end is with the test tear. Today, A powder takes you to learn about a pit that you recently encountered in a project.

demand

The front end uses a rich text plug-in, Ueditor which needs to get the config configuration from the back end when it is initialized.

into the pit experience

Let's start with the initial code:

 @RequestMapping(value = "/getConfig")
    public Object getConfig(HttpServletRequest request){
       return readConfig()；
    }


 /**
     * 读取配置文件
     * @return
     */
    private UedConfig readConfig() {
        String path = this.getClass().getResource("/").getPath();
        FileInputStream fileInputStream = new FileInputStream(path + "config/ued_config.json");
        //读出来,转成对象返回
        ...
    }

That's probably the case with the code, and then after it started up, the front end told me I didn't get the information. N ani, I postman self-test is all right, there is data back. T hen A powder ran to ask the front end, is there a mistake? T he front end says cross-domain. A t that time, A powder was not happy, immediately ctrl-c plus ctrl-v to the back-end processing cross-domain request configuration to the front end. T hen the front end tells me it's jsonp requesting across domains. A powder face forced ??? j sonp cross-domain? I haven't heard of it. F ind a mother-in-law right away, and sure enough, a search is all handled. B ecause it's a springboot project, it's the easiest thing to find. Look at the code:

@ControllerAdvice
public class JsonpAdvice extends AbstractJsonpResponseBodyAdvice {
    public JsonpAdvice(){
        super("callback");
    }
}

Look, it's not easy. I t would be perfect if there were no red lines under the word AbstractJsonpResponseBodyAdvice. D idn't introduce classes? H ow rare is it to pour powder? a lt-enter, uh-huh, what's the situation, no such class? I t's impossible. A sk Dom right away, it turns out that this class is springboot 2.0 or less. S o what do we do? 2 .0 or more doesn't seem to have a way of dealing with jsonp across domains. A powder and in Baidu search ah search, sure enough, the emperor is not responsible for people, A powder see Jackson there is a class JSONPObject can handle, and then A powder changed the code:

@RequestMapping(value = "/getConfig")
public Object getConfig(String callback,HttpServletRequest request){
    return new JSONPObject(callback,readConfig());
}

Then restart, self-test no problem. L et the front end try, you can get it normally. OK, perfect.

The latter project is completed, the front and rear ends are also docked, sent to the test environment, let the tester test. D uang - A bug throws a powder head and gets the configuration fails. I mpossible ah, must be the front end of the problem, run to find the front end for the front end to see. T he front end looked at it and gave me a sentence, the test environment does not cross the domain. I n an instant ten thousand grass Neymar floated over his head. It took a couple of hours to deal with the cross-domain issue, and you told me that the test environment doesn't cross the domain.

Hey, no way, this pot can only be self-tearing resistance. Then A powder changed the code again:

@RequestMapping(value = "/getConfig")
public Object getConfig(String callback,HttpServletRequest request){
    return StringUtils.isEmpty(callback) ? readConfig() : new JSONPObject(callback,readConfig());
}

Still made a compatible, because the front end also needs to even my local debugging. B ut this time should be no problem, A powder heart is still a little proud. Submit the code, send a test, get it done.

Duang- The same bug was thrown on A powder's face again. T he heart is cold, what's going on? T he logs are not wrong. M ash half a day, do not know what reason, A powder can only add log, because in the test environment is not good debugging, there is no error. T hen let the operation match, and then find that this.getClass().getResource("/").getPath() gets the wrong path, A powder once again face, this is not to get the project root path? What's going on?

Then A powder and thick-skinned to find the mother, and indeed found the reason, because springboot integrated tomcat the project is directly run into a jar package, can not be through this.getClass().getResource("/").getPath() this way to get the project root path, can only be obtained through the flow way, and then the powder changed the code:

/**
     * 读取配置文件
     * @return
     */
private UedConfig readConfig() {
    InputStream resourceAsStream = this.getClass().getResourceAsStream("/"+"config/ued_config.json");
    //读出来,转成对象返回
    ...
}

Well, it's finally okay after this submission. Solved the bug, a powder heart beauty.

summary

Often see some small partners say, local docking is no problem, how to test the environment on so many bugs. A powder summed up, mainly the following points:

1. Systems are different, local windows systems are generally, and testing and online are generally linux systems.
2. Local springboot projects run differently, starting through code tools (ideas), while testing and online are started with jar packages.
3. For example, there are some other jar-introduced problems

The above is W3Cschool编程狮 about a common cross-domain problem, accidentally brought three big BUG related to the introduction, I hope to help you.