Wand
API documentation
Overview and Usage
Internals
Introduction
Wand is a password database, integrated in form submit to capture form
data and able to fill forms with stored data. It would not be
impossible to use it as a generic form data database but it's not used
that way today.
Wand will keep passwords in memory and on disk encrypted or
obfuscated. To encrypt it, master password must be enabled in general
and for wand, otherwise a dummy hardcoded password will be used, and
there are already programs (unwand) that has reverse engineered the
code and can un-obfuscate the wand database.
When master password is used, many operations require asking the
user for that password, which means that many operations in wand can't
be performed directly. Instead operations will start but not finish
until later. That means that any code using the wand api must be
prepared for an async behaviour. This is new for gandalf_3
(core-2.1/2008). Previously the master password dialog had to be
synchronous which caused lots of problems.
1. Used OOM policies, Who is handling OOM? and Description of flow
This module uses OP_STATUS where something can fail.
In the function ReportAction that the wandlistener (UI dialog) run,
window->RaiseCondition is called if OOM occurs. (Since UI-folks
usually don't want to care about checking OP_STATUS)
2. Heap memory usage
There is encrypted data stored for each value that is
stored. Proportional to the number of forms and pages that is
stored.
3. Stack memory usage
Low. There is some recursive functions but they don't recurse much.
4. Memory ownership
All memory allocated in the wandmodule should be deleted by the wand
module.
5. Static memory usage
A defaultimplementation of WandListener. (Just a empty
null-implementation).
A couple of variables for initiated status, and storage of a
obfuscationpassword.
6. Caching and freeing memory
The data is loaded from file into memory during startup of opera. It
is keept in memory until opera exits or the user clears/removes info
manually through the UI.
7. Temp buffers
No tempbuffer is used.
8. Memory tuning
No tuning possible. But disabling the ECommerce support will reduce
the memory usage a little
9. Tests
The current test checks for memoryleakage by creating a wandmanager,
opening a file and closing it, as well as performing some common
operations.
10. Coverage
Coverage is probably full. Wand contains quite little code and i'm
pretty sure everything is needed.
There is no automatically way to test coverage.