Skip to content
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.

Sign up for GitHub

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

Jump to bottom

NW & Electron Limitations #621

Open
ronny1982 opened this issue May 22, 2024 · 7 comments
Open

NW & Electron Limitations #621

ronny1982 opened this issue May 22, 2024 · 7 comments

Comments

@ronny1982
Copy link
Contributor

ronny1982 commented May 22, 2024 •
edited
Loading

NW

User-Agent in Background Script not correctly applied

In newer versions of NW, the User-Agent in the background script (navigator.userAgent) defaults to Node.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

if(userAgent !== navigator.userAgent) {

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

if(!win.window || nw.Window.get().window === win.window) {

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
@MikeZeDev
Copy link
Contributor

New Browser Window is inaccessible

Is that a problem in NW.JS or in our code?

@ronny1982
Copy link
Contributor Author

New Browser Window is inaccessible

Is that a problem in NW.JS or in our code?

It's very likely an issue in NW.js

@MikeZeDev
Copy link
Contributor

MikeZeDev commented Aug 4, 2024 •
edited
Loading

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.

@ronny1982
Copy link
Contributor Author

The question is to vague, a detailed explanation is required to answer that.

@MikeZeDev
Copy link
Contributor

MikeZeDev commented Aug 7, 2024 •
edited
Loading

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.

  1. On manga page, chapters links are normal : i.e https://ru.ninemanga.com/chapter/Контратака%20изгнанного%20ученика/5310411.html

  2. If you fetch this link WITHOUT SOURCE as Referrer, you'll stay on original website, and you have a chapter page, where you can work without problem.

image

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 :

image

  1. We will choose "Source 1", https://www.gardenhomefuture.com/go/jump/?type=runinemanga&cid=5310411. Lets call this url LINK B Again, we have to fetch this url using LINK A as Referrer.

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).

  1. FINAL link is displaying first picture of chapter. You can access all pictures url by reading a Javascript variable on the fly.

So, you will tell me : We just have to go through the process and inject a script on FINAL page, right?
Heck, no.

Actually you need TWO THINGS to be able to properly get FINAL page :

  • use LINK B as Referrer
  • a specific cookie telling that we are ok to display the chapter

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
fetch FINAL url using it and proper REFERRER and.... parse the page HTML using regexp to get pages URL 🤦

image

image

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.

win.loadURL(url[, options])
url string
options Object (optional)

httpReferrer (string | [Referrer](https://www.electronjs.org/docs/latest/api/structures/referrer)) (optional) - An HTTP Referrer URL.
userAgent string (optional) - A user agent originating the request.
extraHeaders string (optional) - Extra headers separated by "\n"

I was wondering if it was possible to hack our way by monkey patching document.referrer getter?

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)

@MikeZeDev
Copy link
Contributor

MikeZeDev commented Aug 14, 2024 •
edited
Loading

Another case : manga-download/hakuneko#7329

  • Manga & chapter pages must be acceded with a mobile user agent. Otherwise >403 error.
  • Pages urls are available in a javascript variable.
  • Since we cant set a user-agent on NW window, we cant use FetchWindowScript to gather pages.

The alternative is to do manual fetch and parse page with regexp 🤮

@MikeZeDev MikeZeDev mentioned this issue Aug 17, 2024
Open
@ronny1982
Copy link
Contributor Author

ronny1982 commented Sep 12, 2024 •
edited
Loading

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:

  • Get the raw HTML content using Fetch with the corresponding user-agent header
  • Open a new browser window for the corresponding URL
  • Render the previously acquired raw HTML in the browser window

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@MikeZeDev @ronny1982