How to Serve Apple Pay Domain Association File Using NGINX and Nuxt 3

Steps to Serve the Apple Pay Domain Association File Using NGINX and Nuxt 3

1. Proxy the File to the Nuxt Dev Server

Since the Nuxt 3 development server is already serving the file correctly on localhost:3000, we can configure NGINX to proxy just this specific request to the dev server.

Here’s how you can do it:

NGINX Configuration:

In your NGINX configuration file, add the following block to proxy requests for the Apple Pay domain association file:

location = /.well-known/apple-developer-merchantid-domain-association.txt {
    proxy_pass http://localhost:3000/.well-known/apple-developer-merchantid-domain-association.txt;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

This configuration ensures that when a request is made to access the Apple Pay domain association file, NGINX will proxy that specific request to the Nuxt dev server, where the file is already correctly served.

2. Reload NGINX

After making changes to the NGINX configuration file, you will need to reload NGINX for the changes to take effect. Use the following command to reload NGINX:

sudo systemctl reload nginx

This will restart the NGINX server and apply your new configuration without any downtime.

3. Access the File via Your Domain

Once your NGINX configuration is updated and reloaded, you can verify that the file is being served correctly by navigating to:

https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association.txt

With just a few lines added to your NGINX configuration, you can easily serve the apple-developer-merchantid-domain-association.txt file during the Apple Pay domain verification process. This method works seamlessly with a Nuxt 3 development server, keeping your setup simple and efficient. However, don’t forget to adjust the configuration for production environments when necessary.

By following this guide, you’ll be able to quickly verify your domain for Apple Pay, ensuring that you can securely process payments on your Nuxt-powered site.

Efficient Solution for Vuelidate Nested Validations: Overcoming Maximum Recursive Updates in Vue.js

To resolve the ‘Maximum recursive updates exceeded’ error in Vue.js, often caused by complex nested validations, the implemented solution involves dividing the validation logic across two distinct components. By avoiding deep nesting, this method simplifies the validation process. Each component (‘First.vue’ and ‘Second.vue’) independently handles its segment of the validation logic using Vuelidate. This separation ensures more manageable and modular code, significantly reducing the risk of triggering recursive update errors that are common in tightly nested validation structures. This approach not only enhances code readability and maintainability but also improves performance by preventing the excessive recursive calls that can occur in deeply nested validation scenarios.

Solving Vue 3 Axios CSRF Token Mismatch with Laravel API

While working with Vue 3 and Laravel APIs, a common issue you might encounter is the “CSRF Token Mismatch” error. This problem arises when Axios, a popular HTTP client for making requests, fails to send the necessary X-XSRF-TOKEN in the request header. This article explains how to resolve this issue by intercepting requests and adding the required token.

Understanding the Problem

The Cross-Site Request Forgery (CSRF) Token Mismatch error typically occurs when a request is made from a local domain to a Laravel API. Laravel expects a CSRF token as a part of the request for security purposes. However, when Axios does not include this token in the header, Laravel rejects the request, leading to an error.

The Solution: Intercepting Requests with Axios

The solution lies in modifying the request before it’s sent. By using Axios’ request interceptors, you can ensure that the X-XSRF-TOKEN is included in every request header. Below is a step-by-step guide on how to implement this.

1. Setting Up Axios Instance

First, create an Axios instance with the necessary configurations:

import axios from 'axios';
import Cookies from 'js-cookie';

const httpApi = axios.create({
  baseURL: process.env.VUE_APP_API_URL,
  withCredentials: true,
  headers: {
    "X-Requested-With": "XMLHttpRequest",
  },
});

Here, withCredentials: true is crucial for sending cookies in cross-origin requests.

2. Adding a Request Interceptor

Next, add a request interceptor to Axios:

httpApi.interceptors.request.use(function (config) {
  const token = Cookies.get('XSRF-TOKEN');
  if (token) {
    config.headers['X-XSRF-TOKEN'] = token;
  }
  return config;
}, function (error) {
  return Promise.reject(error);
});

This interceptor function runs before each request is sent. It retrieves the CSRF token from the cookies using js-cookie and adds it to the request headers.

3. Exporting the Configured Axios Instance

Finally, export the configured Axios instance for use in your Vue components:

export { httpApi };

Conclusion

By intercepting requests and adding the X-XSRF-TOKEN header, you can smoothly integrate Vue 3 with a Laravel API without encountering CSRF Token Mismatch errors. This approach enhances the security of your application while ensuring seamless communication between the client and server.

VS Code Path Intellisense config for JavaScript

Edit/Add jsconfig.json

{
    "compilerOptions": {
      "baseUrl": ".",
      "paths": {
        "@/*": ["src/*"]
      }
    },
    "exclude": ["node_modules", "dist"],
    "include": ["src/**/*.vue", "src/**/*.js"]
  }

Edit VS Code settings.json and add

 "typescript.suggest.paths": false,
 "javascript.suggest.paths": false 

How to enable nginx stub status

How to enable nginx stub status

Edit nginx.conf add in the server { ….. } block/context

location /nginx_status {
	# Turn on nginx stats
	stub_status on;

	# I do not need logs for stats
	access_log   off;

	# Security: Only allow access from your IP address #
	allow your ip address;

	# Send rest of the world to /dev/null #
	deny all;
}

For Plesk edit  /etc/nginx/plesk.conf.d/server.conf

Could not open archive dir for / Could not open archive mbox dir

/usr/local/cpanel/scripts/update_mailman_cache

How to fix the errors

Could not open archive mbox dir for somelist: No such file or directory at /usr/local/cpanel/Cpanel/Mailman/DiskUsage.pm
Could not open archive dir for somelist: No such file or directory at /usr/local/cpanel/Cpanel/Mailman/DiskUsage.pm

Solution

If we have a list named list1_webinformat.com the error is

Could not open archive mbox dir for list1_webinformat.com: No such file or directory at /usr/local/cpanel/Cpanel/Mailman/DiskUsage.pm

and we have to create 2 dirs

mkdir /usr/local/cpanel/3rdparty/mailman/archives/private/list1_webinformat.com.mbox
mkdir /usr/local/cpanel/3rdparty/mailman/archives/private/list1_webinformat.com

After we create the needed directories we run 2 commands

/usr/local/cpanel/scripts/fixmailman

/scripts/update_mailman_cache

Let me know in comments if you need any help or if this helped you.
Happy coding 😉

Hot link protection

Simple hot link protection using .htaccess


 RewriteEngine on
 #RewriteCond %{HTTP_REFERER} !^$
 RewriteCond %{REQUEST_FILENAME} -f
 RewriteCond %{REQUEST_FILENAME} \.(gif|jpe?g?|png)$ [NC]
 RewriteCond %{HTTP_REFERER} !^https?://([^.]+\.)?your-domain\. [NC]
 RewriteCond %{HTTP_REFERER} !^https?://([^.]+\.)?google\. [NC]
 RewriteRule \.(gif|jpe?g?|png|bmp)$ http://your-domain/hotlinkdenied [R,L]

  • Replace your-domain with your actual domain name
  • Replace http://your-domain/hotlinkdenied with a valid url