The system uses jeeplus frame (ssm + redis + shiro + mongodb + redis), the default is not done before and after the end of the separation JSP, due to the need to have multiple business needs (the H5, applets, etc.) used by the terminal, it is necessary to achieve separation of front and rear ends. However, since the need to retain the front end of the separation precursor without making new UI and front and rear ends made separate UI, it proposes using a separate set of interfaces used to make the package in which the tip VUE.
There is a business scenario and customers can jump into our system does not need to log in through another system previously used, but because it is not good to do other client systems SSO plus tight schedule. We once with the client system to log in before sending a request to synchronize user information into our system, then we generate a token after a successful login simulated returned to the client system, the system calls the login interface to get the token again, our system after the effective verification token a Relam complete user logs in by writing.
Front end rear end of the frame using a separate ant design vue previous version, the server front-end code do nginx use, when the client system needs to log on, the system has to verify user information and then redirects vue front-end service. Problem encountered, when redirected to the container from the rear end tomcat nginx in damn url was added jessionid unrecognized parameter causes the display 404, returns the following parameters:
http://demo.zzxes.com.cn/ems/#/;JSESSIONID=46ded843b141471c930d95cac006e3d9#/?expoid=7e37cf45f131428ab6b6ed0dcc3f02d4&excompanyType=2
vue router default the back of the # parameter when the routing address, so I can not access, then began the long journey.
Option One:
Since it is a routing problem, the first idea was to modify the default mode HASH HISTORY mode, then get it returned structure:
http://demo.zzxes.com.cn/ems/;JSESSIONID=46ded843b141471c930d95cac006e3d9#/?expoid=7e37cf45f131428ab6b6ed0dcc3f02d4&excompanyType=2
# Of routing problems are solved, but jessionid has been treated as a request address, the same can not access 404, 404 damn, program a failure.
Option II:
There is no way to be able to cook the middle of that jessionid get rid of it? This would solve the problem yet. By Baidu, google has finally found nginx rewrite this function, then modify the configuration file, add the rewrite configuration.
rewrite ^(.*);JSESSIONID)(.*)$ $request_uri/ems/?$args redirect;
reload nginx, the test is successful, program two feasible.
The remaining issues, program two uncertain whether there will be removed jessionid other hidden problems, it can only be found in the settlement.