DEV Community: fireWinters

Introduction to CORS (Cross-Origin Resource Sharing) What is CORS?

fireWinters — Wed, 13 Nov 2024 15:36:22 +0000

CORS, or Cross-Origin Resource Sharing, is a security feature implemented by web browsers that allows or restricts web applications from making requests to a domain different from the one that served the web page. In simple terms, CORS determines whether resources on one domain can be accessed by a web page from another domain.

By default, web browsers enforce the same-origin policy, which blocks web pages from making requests to a different domain than the one that served the page. This is done to prevent malicious websites from accessing sensitive data on other websites. However, sometimes web applications need to request resources from a different origin (domain, protocol, or port), which is where CORS comes into play.

CORS in Action

When a web application on one domain needs to request data from another domain, it sends an HTTP request with specific headers that indicate the origin of the request. The server that hosts the requested resource must then decide whether to allow the request by sending appropriate CORS headers in the response.

For example, if you are building a frontend application hosted on http://example.com, and it needs to fetch data from http://api.example2.com, CORS headers allow the server at api.example2.com to specify whether it will allow requests from example.com.

Common Use Cases

CORS is typically needed in the following scenarios:

Third-party API Access: Many modern web applications rely on external APIs for services like authentication, payment processing, or social media integration. CORS is necessary when these APIs are hosted on different domains.

Frontend-Backend Communication: In cases where the frontend and backend of a web application are hosted on different domains or subdomains, CORS is used to allow communication between them.

CDN (Content Delivery Networks): Websites often use CDNs to serve static assets like images, stylesheets, or JavaScript files. CORS allows the main site to request these resources from a CDN hosted on a different origin.

Key Parameters and Indicators in CORS

Access-Control-Allow-Origin: This header is the most important in CORS and indicates which origins are permitted to access the resource. It can be set to:

A specific origin (Access-Control-Allow-Origin: https://example.com)
A wildcard (Access-Control-Allow-Origin: *), which allows any origin to access the resource. However, this is not allowed for requests that include credentials.
Access-Control-Allow-Methods: Specifies which HTTP methods (such as GET, POST, PUT, DELETE) are allowed when accessing the resource. For example:
Access-Control-Allow-Methods: GET, POST, PUT

Access-Control-Allow-Headers: Lists the HTTP headers that can be used when making the actual request. For instance, if the request includes a custom header like X-Custom-Header, it should be specified here:
Access-Control-Allow-Headers: X-Custom-Header, Content-Type

Access-Control-Allow-Credentials: Indicates whether the request can include credentials such as cookies, HTTP authentication, or client-side certificates. This is important for APIs that require authentication. For example: Access-Control-Allow-Credentials: true

Access-Control-Expose-Headers: Specifies which headers the browser should expose to the requesting client. By default, browsers only expose a limited set of headers like Cache-Control and Content-Type, but Access-Control-Expose-Headers can make additional headers available.

Access-Control-Max-Age: Defines how long the results of a preflight request (see below) can be cached by the browser. It helps improve performance by reducing the number of preflight requests. For example:
Access-Control-Max-Age: 86400 (24 hours)

Preflight Requests: For certain types of requests, especially those that modify server data (such as PUT or DELETE), browsers send a preflight request using the HTTP OPTIONS method. This checks with the server whether the actual request is safe to send. The server's response to the preflight request determines whether the browser will proceed with the actual request.

When Do You Need CORS?

CORS is required when:

Cross-origin requests are made: If your frontend and backend are served from different domains or ports, or if you're accessing external APIs from your application.

Accessing resources hosted on a CDN or third-party service: For instance, if you load fonts, images, or other assets from a CDN, the server must include CORS headers to allow your site to access them.

Security concerns: While enabling CORS allows cross-origin requests, it should be carefully configured to avoid opening up your application to malicious attacks. Only trusted origins should be allowed, and sensitive operations should be protected with additional security measures like authentication tokens.

Conclusion

CORS is a crucial mechanism for ensuring the safe and controlled sharing of resources across different origins. Properly configured, it helps enable modern web applications to interact with third-party services and APIs while protecting users from security risks. Understanding how to configure CORS headers and knowing when and why they are needed is essential for any web developer working with APIs, CDNs, or multi-domain applications.

What are the differences between the Composition API used in Vue 3.0 and the Options API used in Vue 2.x?

fireWinters — Thu, 29 Aug 2024 15:00:38 +0000

The differences between Vue 3.0's Composition API and Vue 2.x's Options API are as follows:

Code Organization:

Composition API: Uses the setup function to centralize the management of a component's state and logic, making the code easier to read and maintain.
Options API: Distributes component state and logic across different options such as data, methods, computed, and watch.
Logic Reuse and Composition:

Composition API: Facilitates easier extraction and reuse of component logic without needing mixins or other abstraction mechanisms.
Options API: Typically requires the use of mixins or higher-order components to reuse logic, which can lead to naming conflicts and tight coupling between components.
Type Support:

Composition API: Being function-based, it integrates more easily with TypeScript (functional programming).
Options API: May require additional type declarations and decorators.
Reactivity Declaration:

Composition API: Explicitly creates reactive state using ref and reactive.
Options API: Reactive state is typically created implicitly within the data option.
Lifecycle Hooks:

Composition API: Lifecycle hooks like onMounted and onUpdated exist as functions within the setup function.
Options API: Lifecycle hooks are defined as component options, such as mounted and updated.
Template Usage:

Composition API: All variables and methods returned by the setup function can be directly used in the template.
Options API: Data and methods in the template need to be defined separately in data, computed, methods, etc.
Dependency Tracking:

Composition API: Provides more granular dependency tracking, where only the actual state in use triggers component updates.
Options API: May cause unnecessary component re-renders in certain scenarios.
Code Splitting and On-Demand Import:

Composition API: Facilitates easier code splitting and on-demand imports since related logic can be more easily organized together.
Options API: Code splitting and on-demand imports are usually more complex and redundant.
Readability and Maintainability:

Composition API: For complex components, it is usually easier to understand and maintain due to the centralized logic.
Options API: For simple components, it may be more intuitive as the API is dispersed.
Community and Ecosystem:

Composition API: As a new feature in Vue 3, it may take time to build an ecosystem around it.
Options API: Already has a mature community and abundant resources.
Both have their advantages and disadvantages, and Vue 3 also supports mixing the two, allowing developers to choose the API that best suits their specific needs.

how to change the author's name in committed git records.

fireWinters — Sun, 18 Aug 2024 13:32:46 +0000

Today I reviewed how to change the author's name in a committed git record.how to fix I've deleted the specific branch on GitHub, but I still see it in my Git records locally.
1.Change the author's name.
git filter-branch is used as an example:

git filter-branch --env-filter '
OLD_EMAIL="old.email@example.com"
CORRECT_NAME="New Name"
CORRECT_EMAIL="new.email@example.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

it works.We should force push our local branch to github.

git push --force origin branch-name

2.Synchronize local and remote git branch records
I've deleted the branch-name branch on GitHub, I still see it in my Git records locally. This can happen because my local repository retains references to the deleted branch.
Here is a solution:

git fetch --prune

I still have a lot to learn

How to find cancer signaling receptor？

fireWinters — Wed, 27 Jul 2022 05:34:00 +0000

I assume that every cell has a special receptor, we call it cancer cell receptor, when the cell becomes cancerous, this receptor is active and can migrate, infiltrate, spread to all parts of the body, and if it can be cured, then It is this receptor that is turned off and is in a dormant state. When the cancer is advanced and the cells are severely damaged, the receptor is also destroyed, and the cancer process cannot be reversed. How to find this receptor?
Here is just a hypothesis, how to verify this hypothesis requires a well-designed experimental plan.