When accessed from internal JS, the route is routed by Vue-router. 内部JSのアクセスでアクセスした際に、Vue-routerでルーティングされてしまう問題

[rifuch]

When accessed from internal JS, the route is routed by Vue-router.

My system uses a Vue.js SPA application on the front end and a Rails API server on the back end.

Vue.js deploys the built files to S3, and the backend API server runs in a Fargate container.

Path allocation is done with CloudFront, with DOMAIN/api/* being sent to the backend and root access being sent to S3.

The problem is that when Vue.js accesses the backend API via GET, the Vue.js Router processes the request and returns a response with a path that does not exist.

Specifically, the problem is as follows:
The Vue.js Store requests access to DOMAIN/api/timeline_owner?target_user_id=:id (:id is a numeric account ID), and the API checks whether the user has permission to view the page. If the user has permission to view the page, the API responds with JSON data and a response code of 200. If the user does not have permission to view the page, the API responds with a response code of 403.
When this operation is performed, the response to DOMAIN/api/timeline_owner?target_user_id=:id requested within the Vue.js Store is the response when the path routed by Vue.js is not specified.
(Response code 200, HTML text)
The contents of this response are output to the console using console.log and confirmed using Chirom's debugging tool, Netework.
Meanwhile, there is also an access log in the API server log running in the container, which shows a response with a response code of 403.

This is a very puzzling operation, and I don't know what's going on.
Are there cases where the Router routes without allowing external access, and if so, are there any settings to avoid this?
The server-side configuration may not be correct in the first place, so I would appreciate any advice on this point as well.

私のシステムでは、フロントエンドにVue.jsのSPAアプリケーション、バックエンドにRailsのAPIサーバーを利用しています。
Vue.jsはビルドしたファイル群をS3に配備、バックエンドのAPIサーバーはFargateのコンテナで稼働させています。
CloudFrontでPathの振り分けを行っており、DOMAIN/api/*はバックエンドに回送され、ルートアクセスはS3に回送される設定です。
起きている問題は、Vue.jsでバックエンドのAPIにGETアクセスした際に、Vue.jsのRouterで処理され、存在しないパスのレスポンスが帰ってきてしまうという問題です。

具体的に起きている現象は以下のような状況です。
DOMAIN/api/timeline_owner?target_user_id=:id(:idはアカウントIDで数値)のアクセスをVue.jsのStoreでリクエストしており、閲覧権限のチェックをAPI側で行い、閲覧権限がある場合はレスポンスコード200でJSONデータをレスポンスしますが、閲覧権限がない場合はレスポンスコード403をレスポンスします。
この操作を行った際、Vue.jsのStore内部でリクエストしたDOMAIN/api/timeline_owner?target_user_id=:idのレスポンスが、Vue.jsでルーティングされているパスが指定されていない場合のレスポンスとなっています。
(レスポンスコード200で内容はHTMLテキスト)
このレスポンスの内容はconsole.logでコンソールに出力したものと、ChiromeのデバッグツールのNeteworkで確認しています。
その一方で、コンテナで稼働しているAPIサーバー側のログにもアクセスログが残っており、こちらはレスポンスコード403でレスポンスしたログが残っています。

非常に不可解な動作で、何が起きているかわかりません。
Routerで外部アクセスをさせずにルーティングする場合があるのか、もしもあるとすればそれを回避する設定などがあるでしょうか？
そもそもサーバー側の構成が正しくないのかも知れませんが、その点も含めてアドバイスいただければ助かります。

Chirome: Networkログ
General -------
Request URL: https://DOMAIN/api/timeline_owner?target_user_id=22
Request Method: GET
Status Code: 200 OK
Remote Address: ***.***.***.***:443
Referrer Policy: strict-origin-when-cross-origin
Response Headers ------
accept-ranges: bytes
age: 13
alt-svc: h3=":443"; ma=86400
content-length: 619
content-type: text/html
date: Thu, 08 Aug 2024 09:56:33 GMT
etag: "****************************"
last-modified: Thu, 08 Aug 2024 01:53:08 GMT
server: AmazonS3
vary: Accept-Encoding
via: 1.1 ************************.cloudfront.net (CloudFront)

CloudWatch log-------
2024-08-08T09:56:45.765Z
    "status": 403,
    "method": "GET",
    "path": "/api/timeline_owner",
    "format": "html",
    "controller": "TimelineOwnersController#show",
    "duration": 61.46,
    "request_id": "******-*******-**************",
    "remote_ip": "***.***.***.***",
    "host": "DOMAIN",
    "url": "https://DOMAIN/api/timeline_owner?target_user_id=22",
    "params": {
        "target_user_id": "22"
    },

[rifuch]

The cause of the problem was not Vue-router, but CloudFront, where the routing was configured.
We apologize for the inconvenience.
問題の原因は、Vue-routerではなく、ルーティングを設定しているCloudFrontにありました。
ご迷惑をおかけしました。

[s3xysteak]

That may be a common problem which caused by HTML5-mode. If you are using hash mode, there is no need to configure proxy. 😄