Closed Wizzzz closed 2 months ago
Hello, how can I repeat the problem according to your description?
Please attach the test code, or at least screenshots or data that differs on the checker depending on the version.
Next, what version do you mean - the plugin/engine or the browser version specified via the useBrowserVersion
?
In any case, the latest updates do not contain critical changes that would affect anonymity, the only significant update is the need to specify the fingerprint service key when launching the browser.
My results with the premium key:
Code example:
require('dotenv/config');
const { plugin } = require('.');
(async () => {
const key = process.env.FINGERPRINT_KEY || '';
const fingerprint = await plugin.fetch(key, {
tags: ['Microsoft Windows', 'Chrome'],
maxBrowserVersion: 'current',
minBrowserVersion: 'current',
timeLimit: '15 days',
});
plugin.useFingerprint(fingerprint);
const context = await plugin.launchPersistentContext('', {
headless: false,
key,
});
const page = await context.newPage();
await page.goto('https://fingerprint.com/products/bot-detection/');
})();
I've just understood the potential reason why it's detected. To create my browser instance, I copy a previously made engine folder and use it as a workingFolder. I had originally done this because of the lock problem.
When I stop using this way of doing things (so I use the classic way), I no longer have a problem and the browser is no longer detected.
I'm going to see if I can stop using this method, but first I wanted to know if the various lock problems were solved with the recent updates? If not, I'll continue to use my old version until it's completely resolved.
Thanks in advance
Currently, errors related to lock files are ignored at least when closing the BasRemote
client. If you still have problems with this on regular versions, please let me know in a separate ticket.
Also, if we talk about other patches (inside your forks, for example), there is no longer a need to replace mutex with other implementations - the problem with blocking at the stage of its creation has been solved.
Okay, so the package can now be used in production with several instances without blocking?
Are there any recommendations to be made where I can run my different programs without making any practical changes?
thank you very much for the various corrections!
I do not know your specific tasks and requirements, but you can work with multiple instances even in one process without creating several separate working folders. There are examples of such code in the repository.
The only disadvantage of this approach is the presence of synchronization at certain stages, due to which the launch of browsers will occur sequentially, however, after launch, you can work in parallel without any problems.
There is also no problem splitting the logic into multiple processes and launching browsers using multiple work folders, if resources allow.
Most often, when working with the first option, problems with lock files arise, but we cannot delete this logic, however, we can ignore some cases, so above I asked you to write about problems with this, if they arise.
If you need complete security in terms of the absence of race conditions and so on, I would recommend using additional synchronization methods (when working with multiple browsers within the same process). For example, using the async-lock
library, you can implement a lock and consider the places where the fetch and launch methods are used as a critical section.
For the most part, all this concerns the design and implementation of specific projects, so I can't think through all the logic, but I can fix obvious problems if there is a detailed report and a method of repetition.
Hello, since the last update, browsers are detected on fingerprint.com
https://fingerprint.com/products/bot-detection/
I've just tested on an old version of the browser and I don't have the problem.