If the front-end and back-end are separated, will the server be unable to set cookies?
mistake. The separation of front-end and back-end does not mean that the server cannot set cookies. In an architecture where front-end and back-end are separated, the front-end usually communicates with the back-end through API calls instead of directly rendering the HTML page generated by the back-end. This prevents the server from setting cookies in the response like traditional server-side rendering applications.
However, the server can still set the cookie and send it to the client via the Set-Cookie header in the response. In a front-end and back-end separation architecture, this is usually done after a successful login or authentication, so that the server can store the authentication token or session information in a cookie and verify it on subsequent requests.
The front-end application (usually JavaScript) can read and process these cookies from the response, then send them back to the server as part of the request headers in subsequent API requests. This allows the server to use the cookie on subsequent requests to authenticate the user or provide other session-related functionality.
To summarize, although the front-end and back-end separation architecture changes the way the server sets cookies, the server can still set cookies in responses and handle session and user authentication through API requests and responses.
The front-end and back-end separation server can also set cookies for the browser.
First, you need to understand how the server sets cookies for the browser.
In the proportional backend, taking php as an example, setcookie() is called;
But this is just an appearance. The specific setting mechanism is to add set-cookie information to the header returned to the browser, for example:
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMTThe browser sets cookies based onresponse header, so it has nothing to do with the separation of front-end and back-end.
Cross-domain situation between front-end server and back-end server
When there is a cross-domain situation between the front-end server and the back-end server, setting cookies will be restricted. Cross-domain means that in the browser, the domain of the front-end application is different from the domain of the back-end server.
In cross-origin situations, by default browsers prevent cross-domain cookies from being set via the response's Set-Cookie header. This is to protect user privacy and security. Browsers follow the same-origin policy, which requires that a web page can only access resources from the same origin.
However, there are ways to get around this limitation:
CORS (Cross-Origin Resource Sharing): The backend server can allow specific cross-domain requests by setting the appropriate CORS response headers, including allowing cookies to be carried. For example, you can allow cross-domain requests to carry cookies by setting the "Access-Control-Allow-Origin" header to the domain of the front-end server, and setting the "Access-Control-Allow-Credentials" header to "true".
Proxy server: The front-end server can forward requests through the proxy server, send cross-domain requests to the back-end server, and set cookies on the proxy server. In this way, the communication between the front-end server and the back-end server will not be restricted by the browser's same-origin policy.
It should be noted that if there is a cross-domain situation, security and privacy need to be considered when setting cookies. Ensure that cross-domain requests are only allowed to carry cookies when necessary, and requests are properly verified and authorized to prevent potential security vulnerabilities.
How to determine cross-domain
In front-end development, determining whether a cross-domain request is usually based on the following three factors: protocol, domain name, and port number. If any of the factors are different, it is considered a cross-domain request.
For example, assuming the front-end application is running on http://a.log.com, here are some examples for determining whether a cross-domain request is:
Cross-protocol request: If the front-end application is running through http://a.log.com, but the requested URL starts with https://, such as https ://b.log.com/api/data, is considered a cross-domain request because the protocols are different.
Cross-domain request: If the front-end application is running through http://a.log.com, but the requested URL starts with http://b.log.com Starting with /api/data, or simply using a different second-level domain name, such as http://subdomain.log.com/api/data, it is considered a cross-domain request.
Cross-port request: If the front-end application is running through http://a.log.com:8000, but the requested URL starts with http://a.log .com:9000/api/data, or if a different port number is used, it is considered a cross-domain request.
It should be noted that the same-origin policy in the browser will restrict access to cross-domain requests for security reasons. Access to cross-domain requests can be allowed by using CORS (Cross-Origin Resource Sharing) or other cross-domain solutions.
The front-end server forwards requests through a proxy server and handles cross-domain
Configure proxy server settings on the front-end server: The front-end server needs to configure a proxy server to receive cross-domain requests and forward them to the back-end server. This can be achieved by using common proxy server software (such as Nginx, Apache) or a custom proxy server script.
Front-end application sends request to proxy server: When a front-end application sends a cross-domain request, it sends the request to the proxy server address on the front-end server instead of directly to the back-end server. For example, a front-end application sends a request to http://frontend-server/proxy.
The proxy server forwards the request to the backend server: After the proxy server receives the request from the front-end application, it forwards it to the corresponding address of the backend server. For example, the proxy server forwards requests to http://backend-server/api.
The backend server processes the request and sets the cookie: After the backend server receives the request forwarded by the proxy server, it processes it accordingly and sets the cookie in the response (if necessary). The backend server can handle the request based on business logic and include the Set-Cookie header in the response to set the cookie.
The proxy server returns the response to the front-end application: after the back-end server processes the request, it sends the response back to the proxy server.
The proxy server returns the response to the front-end application: After the proxy server receives the response from the back-end server, it returns it to the front-end application. The front-end application can handle it accordingly after receiving the response.
By using a proxy server, front-end applications can bypass the browser's same-origin policy restrictions and enable cross-domain communication between the front-end and back-end servers, while allowing the setting and processing of cookies. Specific implementation details and configuration methods may vary depending on the selected proxy server software or custom scripts, and therefore require corresponding configuration and development based on the specific situation.
Same Origin Policy RestrictionsExplanation
In fact, the same origin policy is mainly a security mechanism implemented by browsers to restrict client script access between different sources (protocol, domain name, port). The same-origin policy does restrict the access of front-end applications in the browser to servers of different origins, but in communication between servers, the same-origin policy does not apply.
When communicating between servers, they are not restricted by the browser's same-origin policy. Communication between servers can freely make cross-domain requests and responses and share data because servers can directly access resources without going through browser security restrictions.
Therefore, if you use a proxy server in a front-end application to forward requests to a back-end server, the communication between the proxy server and the back-end server is not restricted by the browser's same-origin policy. This allows the setting and handling of cookies on the proxy server, as well as the handling of cross-domain requests and responses.