-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NW & Electron Limitations #621
Comments
Is that a problem in NW.JS or in our code? |
It's very likely an issue in NW.js |
Is there a possibility to hack your way to set user agent or referrer in NW js window? Object.defineProperty(document, "referrer", {get : function(){ return "my new referrer"; }});
Object.defineProperty(navigator, "userAgent", {get : function(){ return "My totally not suspicious browser"; }}); I am mentioning referrer because it may be handy for a nasty website we know. |
The question is to vague, a detailed explanation is required to answer that. |
Case : TAADD, Tenmanga, NineManga (All of them but RU is the problem) Manga : https://ru.ninemanga.com/manga/Контратака+изгнанного+ученика.html Lets call NinemangaRU the SOURCE website.
You can see here its unusable on russian part of ninemanga as they miss all pics (404 errors) 2bis) If you fetch this link WITH SOURCE as Referrer, you get redirected to a dummy website (LINK A: https://www.financewealthloans.com/go/runm/5310411 ) where you have to chose a source server :
The content is quite simple : <!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1">
<title></title>
<META content="" name=Keywords>
<META content="" name="Description">
<link rel="shortcut icon" href="/files/images/yyzz/favicon.ico" type="image/x-icon">
<meta property="og:type" content="website" /></head>
<body>
<script language="javascript" type="text/javascript">
window.location.href="/statuses/2980106.html";
</script>
</body>
</html> Nothing fancy. Its uses javascript to redirect to https://www.gardenhomefuture.com/statuses/2980106.html (Lets call it FINAL).
So, you will tell me : We just have to go through the process and inject a script on FINAL page, right? Actually you need TWO THINGS to be able to properly get FINAL page :
We cant set a custom referrer when we inject Javascript using NWJS. So we cant use JS injection. Providing that the cookie is easy to forge using chapterid (5310411.html) and the id of FINAL page (2980106.html), we can Concrete problem : Sometimes we must execute Script in Window but in order to get correct content, the request used need a particular Referrer, and perhaps Cookies. I had to parse the javascript using regexp to get what i wanted because no refererr change possible . I had to forge a cookie when it should have just being available. Ewww. For now we cant set a Referrer on NWJS windows, i think we can with Electron windows.
I was wondering if it was possible to hack our way by monkey patching If we dig a big i think we can find similar cases like LectorManga (where you just CANT DO like we do with Tumanga, ive checked) |
Another case : manga-download/hakuneko#7329
The alternative is to do manual fetch and parse page with regexp 🤮 |
No, the user-agent cannot be modified in new browser windows. This would also interfere with the global user-agent which is used to bypass CloudFlare. However, it is possible to inject fakes with FetchWindowPreloadScript. Possible Solution:
|
NW
User-Agent in Background Script not correctly applied
In newer versions of NW, the User-Agent in the background script (
navigator.userAgent
) defaults toNode.js/21
.This results in always triggering the restart notification when assigning a User-Agent, even when the real User-Agent didn't changed.
See also: nwjs/nw.js#8162
Affected:
haruneko/app/nw/src/ipc/RemoteProcedureCallContract.ts
Line 27 in 1874bcf
New Browser Window is inaccessible
When using a browser window to fetch a request (e.g., bypass CloudFlare) the window may be empty (no DOM or JavaScript access) or may have the same content as the application window.
Affected:
haruneko/web/src/engine/platform/nw/FetchProvider.ts
Line 215 in 6ffcea9
MediaSource not supported
When initialising a video element based on media source to stream frames, NW.js seems not to support the necessary
MediaSource
type. Also audio is missing in normal embedded MP4 video streams. May be related to proprietary codecs.Extension Manifest V3
With Chrome's deprecation of Manifest V2 it is expected that migrating to V3 becomes necessary sooner or later. Since V3 blocks the execution of remotely hosted code, this may become a major deal breaker since HakuNeko is an hosted web-app which is executed locally.
Electron
TBD
The text was updated successfully, but these errors were encountered: