You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update local network access FAQ and screenshots (#979)
* Update local network access FAQ and screenshots
* Update last modified date and clarify local network access behavior for Chromium 145+
* Update local network access FAQ with revised content and add LNA permission prompt image
* Clarify Local Network Access settings for Chrome 142-144 in troubleshooting guide
* update timestamp
breadcrumbText: Error message - Permission was denied for this request to access the unknown address space
8
8
description: CORS unknown address space
9
9
date: 2025-11-04 17:21:42 +0800
10
-
last_modified: 2025-12-17 16:00:00 +0800
10
+
last_modified: 2026-02-12 10:20:00 -0800
11
11
---
12
12
13
13
# Error Troubleshooting
14
14
15
15
> [!IMPORTANT]
16
-
> This is a newly developing issue, and as such the information in this article may change over time.
16
+
> This is an evolving browser behavior. Details in this article may change as Chromium updates Local Network Access.
17
17
18
-
## Error message - CORS Errors caused by local network access permissions when using Chromium 142 and later
18
+
## Error message - CORS errors caused by local network access permissions in Chromium 142 and later
19
19
20
20
### Overview
21
21
22
-
Starting in **Chromium-based browsers v142+** (released Oct 28, 2025)—including Chrome, Edge, Brave, and Opera—Dynamsoft Web TWAIN Service may not work as expected due to new **Local Network Access (LNA)** restrictions that limit requests **from public network locations to private and loopback network locations**.
22
+
Local Network Access (LNA) is a browser security model that has been enforced in Chromium-based browsers since version 142 (released October 28, 2025), including Chrome, Edge, Brave, and Opera. It blocks web apps from reaching local or loopback targets unless the user explicitly grants permission, which can affect Dynamic Web TWAIN Service behavior.
23
+
24
+
These restrictions limit requests from **public network locations** to **local or loopback locations** unless the required site permission is granted.
25
+
26
+
Starting in **Chrome 145**, the site-setting label changed from one permission to two:
27
+
28
+
-`loopback-network` shown as **Local Network**
29
+
-`local-network` shown as **Apps on device**
30
+
31
+
Dynamic Web TWAIN Service communicates with `localhost` / `127.0.0.1`, so **Local Network** (`loopback-network`) is the key permission for most deployments.
32
+
33
+
When your page first requests local access, Chromium will show an LNA permission prompt.
34
+
This FAQ and the symptoms below apply when users dismiss this prompt or click **Block**.
#### **2) Initialization succeeds, but scanning / loading returns blank**
34
48
Initialization appears successful, but scanned or loaded images are blank.
35
49
36
-
The browser console (F12 → Console) may show a CORS denial similar to:
50
+
The browser console (`F12` -> `Console`) may show a CORS denial similar to:
37
51
38
52
```shell
39
53
Access to fetch at 'https://127.0.0.1:18623/fa/VersionInfo?ts=1761893667670'
40
54
from origin 'https://your-domain.com' has been blocked by CORS policy:
41
55
Permission was denied for this request to access the `unknown` address space.
42
56
```
43
57
44
-
This error occurs because the web page is loaded from a public network origin (for example, `https://your-domain.com`) and is attempting to connect to a loopback network location (`127.0.0.1`), which Chrome now treats as a protected localnetwork request.
58
+
This happens because a page on a public origin (for example, `https://your-domain.com`) is trying to access a loopback address (`127.0.0.1`), which Chromium now treats as a protected local-network request.
45
59
46
60
---
47
61
48
62
#### Version-Specific Behavior
49
63
50
-
The observed behavior depends on Chromium browser version and Dynamic Web TWAIN (DWT) version:
64
+
Observed behavior depends on Chromium version and Dynamic Web TWAIN (DWT) version:
51
65
52
-
| Browser Version | DWT Version| Resulting Symptom |
> (*) **Chromium 145, which can also block websocket, has not been officially released.**
59
-
> Behavior is based on pre-release testing and may change once the final release becomes available.
60
-
> Edge 143 and Firefox Nightly will have local network permission control as well.
72
+
> [!NOTE]
73
+
> (*) Blocking WebSocket requests is on Chromium's roadmap, and may be enforced in a future release.
74
+
> Other browsers are also introducing local network permission controls.
61
75
62
76
### Root Cause
63
77
64
-
Chromium 142 introduces and enforces a new [Local Network Access (LNA)](https://chromestatus.com/feature/5152728072060928) security model that restricts requests **from public network locations to private and loopback network locations**, requiring explicit user permission.
78
+
Chromium 142 introduced [Local Network Access (LNA)](https://chromestatus.com/feature/5152728072060928), which restricts requests from public network locations to local/loopback network locations unless permission is granted.
65
79
66
80
> [!NOTE]
67
-
> For background and design rationale, see Chrome’s Developer Blog: [New permission prompt for Local Network Access](https://developer.chrome.com/blog/local-network-access).
81
+
> For background and design rationale, see Chrome's developer blog: [New permission prompt for Local Network Access](https://developer.chrome.com/blog/local-network-access).
68
82
69
-
Under this model, **requests originating from a public network location** (such as a publicly hosted website) **to private or loopback network locations**(including localhost and 127.0.0.1) are blocked by default unless the user explicitly grants permission.
83
+
Under this model, requests from a public origin (a publicly hosted site) to local or loopback targets (including `localhost` and `127.0.0.1`) can be blocked by default.
70
84
71
-
Dynamic Web TWAIN relies on a locally installed service that listens on a loopback address. When a web application hosted on a public domain attempts to communicate with this service, Chrome categorizes the request as a **public-to-local** network request, which now requires explicit user consent.
85
+
Dynamic Web TWAIN relies on a locally installed service that listens on a loopback address. If browser permission is not granted, communication with that local service fails.
72
86
73
87
### Resolution
74
88
75
89
> [!WARNING]
76
-
> The steps outlined below **do not “fix” or bypass this restriction**, nor can Dynamic Web TWAIN override it programmatically. They simply ensure that the browser’s required permission is correctly granted so the local Dynamic Web TWAIN service is allowed to communicate with your application.
90
+
> This is driven by browser security policy decisions. Dynamic Web TWAIN cannot bypass these restrictions programmatically.
91
+
> Browser behavior will continue evolving, and temporary workarounds may be removed in future versions. You should plan your deployment and UX flow around current browser permission requirements.
77
92
78
-
***1. To Manually Correct This in Chrome***
93
+
***1. To manually correct this in Chrome***
79
94
80
95
- Navigate to your Dynamic Web TWAIN page.
81
96
- Click the lock/settings icon in the browser address bar.
82
-
- Ensure that **Local Network Access** is enabled.
97
+
- In **Chrome 142-144**, ensure **Local Network Access** (`local-network-access`) is `Allow`.
98
+
- In **Chrome 145+**, check:
99
+
-**Local Network** (`loopback-network`) is `Allow` (required for `localhost` / `127.0.0.1`)
100
+
-**Apps on device** (`local-network`) is `Allow` only if your app also needs private-network device access
> If Dynamic Web TWAIN is running inside an iframe from a different origin (cross-origin), you must explicitly grant local-network access in the iframe.
103
-
> If the iframe is same-origin, no additional configuration is required.
122
+
> If Dynamic Web TWAIN runs inside a cross-origin iframe, local-network permissions must be explicitly allowed in the iframe`allow` attribute.
123
+
> If the iframe is same-origin, no additional iframe permission configuration is required.
104
124
105
-
To enable access, specify the `allow` attribute.
106
-
For security reasons, it is recommended to allow only the necessary origin rather than using a wildcard.
125
+
For Chrome 145+, use `loopback-network` (and `local-network` only if needed). For older versions, include `local-network-access`.
console.log(`Local network access is currently denied.\n\nPlease go to:\n${settingsUrl}\nand enable 'Local network access' permission for this site.`);
134
-
// Optionally show a UI guide or help link here.
135
-
} elseif (state ==="prompt") {
136
-
alert("To connect with the local scanning service, Chrome will ask for 'Local network access' permission.\n\nPlease click 'Allow' when prompted.");
137
-
// Proceed to init DWT after this message.
138
-
// e.g., Dynamsoft.DWT.Load() or CreateDWTObjectEx or your init DWT function
"To connect with the local scanning service, Chrome may ask for Local Network permission. "+
185
+
"Please click Allow when prompted."
186
+
);
187
+
}
188
+
189
+
// Proceed with DWT initialization.
190
+
// e.g., Dynamsoft.DWT.Load() or CreateDWTObjectEx(...)
152
191
})();
153
192
```
154
-
If the permission is not granted, consider displaying a user-friendly message directing them to:
155
193
156
-
> Chrome → Settings → Privacy and Security → Site Settings → Local network access
194
+
If permission is not granted, direct users to:
157
195
158
-
This approach provides a more polished user experience, especially during onboarding or troubleshooting.
196
+
> Chrome -> Settings -> Privacy and security -> Site settings -> Local Network / Apps on device
159
197
160
198
### Product Improvements Related to Local Network Access
161
199
162
-
Dynamic Web TWAIN v19.3 introduces **user-experience enhancements** to better surface localservice connectivity and permission issues.
200
+
Starting from v19.3, Dynamic Web TWAIN now includes UX enhancements to better surface local-service connectivity and permission issues.
163
201
164
-
These changes **do not alter or bypass Chromium’s security model**. Their purpose is to make permission-related failures easier to identify and understand, and to guide users to the appropriate browser settings when access is blocked.
202
+
These changes do not alter or bypass Chromium's security model. They make permission-related failures easier to identify and guide users to the correct browser settings.
165
203
166
204
The key improvements include:
167
205
168
-
***Explicit detection of blocked local network access**\
169
-
When the browser blocks communication with the local service, a clear dialog is displayed explaining the cause and directing users to this FAQ.
206
+
-**Explicit detection of blocked local network access**
207
+
When the browser blocks communication with the local service, a clear dialog explains the cause and directs users to this FAQ.
-**Clearer messaging during service installation**
214
+
The service installation dialog explains that connection failure may be caused either by missing service installation or denied local-network permission.
***Clearer messaging during service installation**\
176
-
A notice is added to the service installation dialog to inform users that a connection failure may be caused either by the service not being installed or by local network access being denied, as these two cases cannot be reliably distinguished.
0 commit comments