I have one or more servers, one of which is responsible for business logic, stores all business data, and provides only private api interfaces. Temporarily named as an API server. The second server is provided to public accounts or webpage pages. It mainly stores static html and js and partially connects to the API server... I have multiple servers.
One of them is responsible for business logic, saving all business data, and providing only private api interfaces to external users. Temporarily named as an API server;
The second server is provided to public accounts or webpages. It stores static html and js files and PHP files that are connected to API server interfaces. Temporarily named WECHAT server.
During use, a user can only access the WECHAT server, send a request to the WECHAT server, and request the api server through the private strong encryption API interface of the server, so that the external access permission can be determined by the openid.
However, there is A new requirement. The API server provides A new function and its resources are open to users with attribute, the associated information of attribute A and openid is stored on the API server (both mysql and redis are saved ), however, on the WECHAT server, I want to provide users with the permission to access this resource.
The current methods are as follows. Please help us decide which one is better or whether there is a better one.
1. The WECHAT server directly accesses the data tables on the API server. This can be achieved physically, but it is too logical for different services to access data across servers.
2. Create an API: ifOpenidHasA on the API server. This is a waste of resources and slows down the system.
3. Check resource A interface to determine whether the WECHAT server request carries parameter A when requesting resource. This seems to be okay now, but what if there is a parameter ABCD that corresponds to different resources in the future? And if a super administrator has all the permissions, the parameter cannot be understood.
Supplement: some points may not be clear. Add:
The API is encrypted. Currently, only the encrypted traffic sent by the WECHAT server can be accessed. Currently, the API server can only access the WECHAT server, which is invisible to the outside. In the future, we do not plan to make open APIs. They are all used by WECHAT servers or their own apps and encrypted. Now we can think that the WECHAT server is actually a client (cloud client or WEB client ).
However, if you really want to create an APP after such consideration, method 1 may be unavailable.
Reply content:
I have multiple servers.
One of them is responsible for business logic, saving all business data, and providing only private api interfaces to external users. Temporarily named as an API server;
The second server is provided to public accounts or webpages. It stores static html and js files and PHP files that are connected to API server interfaces. Temporarily named WECHAT server.
During use, a user can only access the WECHAT server, send a request to the WECHAT server, and request the api server through the private strong encryption API interface of the server, so that the external access permission can be determined by the openid.
However, there is A new requirement. The API server provides A new function and its resources are open to users with attribute, the associated information of attribute A and openid is stored on the API server (both mysql and redis are saved ), however, on the WECHAT server, I want to provide users with the permission to access this resource.
The current methods are as follows. Please help us decide which one is better or whether there is a better one.
1. The WECHAT server directly accesses the data tables on the API server. This can be achieved physically, but it is too logical for different services to access data across servers.
2. Create an API: ifOpenidHasA on the API server. This is a waste of resources and slows down the system.
3. Check resource A interface to determine whether the WECHAT server request carries parameter A when requesting resource. This seems to be okay now, but what if there is a parameter ABCD that corresponds to different resources in the future? And if a super administrator has all the permissions, the parameter cannot be understood.
Supplement: some points may not be clear. Add:
The API is encrypted. Currently, only the encrypted traffic sent by the WECHAT server can be accessed. Currently, the API server can only access the WECHAT server, which is invisible to the outside. In the future, we do not plan to make open APIs. They are all used by WECHAT servers or their own apps and encrypted. Now we can think that the WECHAT server is actually a client (cloud client or WEB client ).
However, if you really want to create an APP after such consideration, method 1 may be unavailable.
I canceled my previous answers. I think I am not on a single channel with your ideas, so the answer is completely awkward.
My idea is to ensure security through authorization, but your idea is to ensure security through data encryption. I think the performance difference between the two is obvious, now, when you find that relying solely on encryption cannot solve all the problems, you are worried about the performance loss caused by security authentication...