Jump to content

Recommended Posts

Posted

Modifying Firefox to auto save the login information to the Firefox Saved Passwords manager without prompting was easy for version 3 because you can directly edit the JS files from the program’s folder to apply the changes. However, the file structure was a bit different starting from Firefox 4 until the current version 15. We researched and found that it is still possible to force Firefox to auto save the password without the popup notification.

 

For Firefox 3 : all you need to do is edit the nsLoginManagerPrompter.js file with a text editor preferably Notepad++ located in C:\Program Files\Mozilla Firefox\componenets\ folder. Search for the _showSaveLoginNotification function and replace the whole code that is highlighted in yellow…

 

ns_Login_Manager_Prompter.png

 

With the following code:

 

var pwmgr = this._pwmgr;
pwmgr.addLogin(aLogin);

 

The end result would look like the image below.

 

ns_Login_Manager_Prompter_edited.png

 

Save the changes that you’ve made on the nsLoginManagerPrompter.js file and whenever you login to any website, Firefox will auto save the site, username and password to the login manager WITHOUT showing the notification bar. You can access the saved password area by going to Tools > Options > Security and click the Saved Passwords button. There is one possible bug which is even when a user entered the wrong username or password, it will still be saved.

 

 

As for Firefox 4, it gets slightly difficult because the nsLoginManagerPrompter.js file is archived in an omni.jar file located at C:\Program Files\Mozilla Firefox\ folder.

 

Starting from Firefox 5, you may have noticed that editing the nsLoginManagerPrompter.js inside omni.jar file does not work. The Firefox developing team did not fix the bug nor improve the security but instead they optimized it further by making Firefox load a compiled binary version of the nsLoginManagerPrompter.js file instead of the raw and editable JS file. Here is what you need to do to enable auto password saving on Firefox 5 and above. Do take note that the omni.jar file has been renamed to omni.ja starting from Firefox 10.

 

1. Use WinRAR, PowerArchiver or WinZIP to open the omni.jar or omni.ja file from C:\Program Files\Mozilla Firefox\ folder.

2. Navigate to jsloader\resource\gre\components\ and delete the nsLoginManagerPrompter.js file.

 

delete_nsloginmanagerprompter.png

 

3. Go back to the root of omni.jar or omni.jar, and navigate to components folder. Edit the nsLoginManagerPrompter.js file and replace the whole _showSaveLoginNotification function as shown earlier. Save the changes and go back to the archiver. Click the Yes button when the archiver prompts you to update the archive with the updated file.

 

 

Important Notes:

 

 

1. Whenever Firefox gets updated, most likely the omni.ja file will be reverted to the original

2. This article and research is for educational purposes only. Use it with care and think twice before implementing this illegally as it can get you into a lot of trouble!

 

 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Posts

    • There is no need for gRPC in this case, even tho originally it was gRPC based but since we don't need it to be bi-directional, we switched to simple http requests for the web calls and SSEs for the data streamed from the server. There are distributed locks in place to precent race conditions between actions that can happen between multiple web instances and the server.   Local models can also be slow depending on the model, and most external models can actually be faster than local ones if you use Flash 2.5 or something along those lines. I am running on 512GB of Unified Memory on my Mac Studio M3 Ultra so the speed of the local model for a small model is pretty good but I tested it with Gemini too and it works equally as fast and in some cases faster. The way it works is that I'm using pgvector (one of the benefits of moving to Postgres) to search the data and see what the player can see etc and there is some batching of the next few actions for 2-4 seconds for the user until the next LLM request fires. The batching also includes branching on logic so if they for example fall under some HP they will move to kiting instead of attacking or maybe they heal etc.   Everything is authed and permission-based. The server and the backend of the frontend have secure communication between them, either with a symmetric key (not recommended for production) or a certificate (the recommended way), so there is no worry. It's all tied to the account's access level, etc., so nobody can make an action that they normally wouldn't be allowed to do. Even the MCP is token-based, and there are prompt injection protections in place. The MCP is audited, and every mutation needs confirmation. The admin area is only accessible to the admin account anyway so normal users can't access it.  
    • First of all, its great to finally have something meaningful to discuss on this forum  and good job pushing this community forward, even if its mostly dead. I always wondered why, in the last 15 years, no one has properly documented any of the source code (acis mobius) or at least exposed common functionality through something like a rest api, which is straightforward enough for most people to understand and use.   I have some technical questions since im really interested   Regarding real time features like maps and enchanting  are you using technologies like grpc? And what happens when both a logged in player and panel try to enchant the same item at the same time? Do we run into a race condition how do you handle that ?   Regarding  fake player system  external models calls typically take 1-2 seconds to respond, while an local models might take around 200-300ms. During that time a lot can happen in game. So when the plan becomes stale you override it and wait for the new one  meaning the node handles everything in real time and the LLM simply sets the goal asynchronously. Is that the correct understanding ?   Regarding the security aspect a lot can go wrong when exposing crucial server logic to the open web (experimental is good). My real concern is  the mcp in the panel where  a lot can go wrong with bad user input.      Wasn't the game client always the limiting factor for l2j?
    • Migrating a legacy Interlude server to PostgreSQL while adding real observability is basically forcing 2006 MMO engineering to attend a 2026 infrastructure conference at gunpoint. PS: which revision of aCis? PS: 🧻what was broken during this whatever you call it.    AAC Guard beign asked to adapt to this be like: - Creating bugs since early 2018
    • OH MY LORDDDDDDDDDDDDDDDDDDDDD   FINALLY
  • Topics

×
×
  • Create New...

Important Information

This community uses essential cookies to function properly. Non-essential cookies and third-party services are used only with your consent. Read our Privacy Policy and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..