-
Notifications
You must be signed in to change notification settings - Fork 2
History
This is the full history of the OPWS project, as of February 4 2017, in terms of what happened when: slightly higher-level than just the raw Git commits ("some profiles were added, changed, or removed" is an implicit line between each item here), and with more insight into the non-Git-based history of the project (though I'm starting from there to refresh my memory about the exact timeframe for this stuff).
@stuartpb begins work on a password management project (blot.pw), which includes a "sites.yaml" file that documents the password reset and change links for a handful of websites, as well as rules for a few of them (alongh with some documentation of HTTPS support).
Having added a few more sites to the list and realizing that this undertaking deserves its own project, the sites.yaml file is removed from the blot.pw project and re-introduced as a set of YAML files in a new "domainprofiles" repository under the opensets organization.
Contrary to the flat-file-with-domains-as-keys approach of the monolithic sites.yaml, data in domainprofiles is initially organized as individual files under directories by public suffix (so, for example, GitHub's profile would be under "com/github.yaml").
There's no testing, and there isn't even really a well-defined schema. The most basic fields are documented in README.md, but data beyond those fields is documented in an ad-hoc fashion, with representations for more complex information invented on the fly, sometimes even inconsistently with previous representations for the same kind of info.
A Gruntfile to compile all profiles into a single JSON flatfile is written, followed shortly behind by a test script that verifies that all files parse as valid YAML, and fit the correct naming convention (avoiding forgotten file extensions or redundant domain suffixes).
Travis CI integration is introduced alongside the tests, and changes start being vetted via pull request instead of just tossing them directly onto the tip of master as they were done before.
The first issue on the project is filed, kicking off the first major refactor for consistency and extensibility.
The "yaml" directory containing all profiles is renamed "profiles", because "yaml" is redundant and not descriptive of the content.
The CONTRIBUTING.md is added, along with an update to the documentation to make it more closely reflect the new profile structure.
Fields for documenting password "must contain" requirements are added, along with more consistency around black/whitelisting.
username.remind is changed to more closely resemble the fields of password.
More fields commonly seen in profiles are documented in README.md, including register, login, and questions ("register" and "login" having been previously "documented" in the form of issue #3).
Captcha, usability, and reauth fields are documented and made consistent across profiles (though, since there's nothing in place to verify that profiles fit the schema as documented, mistakes still pop up from time to time).
More fields are documented in README.md, and the full path to each field is used in the headings instead of implying them via nesting.
"register" and "login" are added as part of the template in CONTRIBUTING.md.
An issue is raised about many profiles having a value of token for password.reset.response, which isn't very useful. This kicks off a series of reviews that won't fully come to be resolved until the issue is finally closed in February 2017.
Probably the most significant leap in the project's history to date:
- Badges for test status and Gitter are added.
- Field documentation is moved out of README.md and into its own file, docs/fields.md.
- A test is added to verify that profiles only contain documented fields. This leads to several fields that were not previously documented (or documented correctly) getting added to the documentation, as well as catching several profiles that were broken in some way.
As this isn't a proper schema validation, it doesn't catch all incorrect uses of a field, but it catches enough to make the whole database consistent for the first time.
In light of how frustrating it was to deal with many different, inconsistently-authored, and increasingly out-of-date profiles, especailly in the face of increasingly-high standards for what a profile should contain, the reviewed field is introduced (and quickly extended to reviewed.date).
password.reset.response is split into an object containing body (the old value of the field) and sender (arguably the more useful information to record).
The versioning scheme is laid out in issue #7, and the content policy is described by issue #9.
Issue #10 is opened to discuss documenting login persistence.
The topic of localizing profiles is broached with issue #12.
A first design for a planned API is laid out with issue #13.
The awkward field password.reset.token.reset, and its accompanying stopgap documentation, is removed.
Issue #19 is opened, calling for a review of all existing profiles. The expectation is that reviewing profiles at a casual pace, one or two at a time in spare moments, will end up with all profiles being reviewed eventually, at which point a review date can be mandated for all profiles.
The reality is that, by the beginning of February 2017, only 38 profiles will have a reviewed.date field, many of which were introduced after this issue was filed. Skip ahead if you want to know how that was resolved.
Three more issues discussing prospective field extensions are opened.
The MIT license that the repo was initialized with (almost reflexively) is replaced with the more-properly-suited Open Database License.
Travis CI is replaced with Circle CI.
Fields for session invalidation on password change are added.
Usability fields are split into objects, closing issue #15 from April.
Third-party login providers are moved from login.thirdparty to thirdparty.auth.providers, per issue #31.
An issue is opened calling for use cases to guide the schema going forward.
Many other issues are opened, ranging in their concerns from profile fields to better tooling.
GitHub having introduced protected branches in September 2015, the master branch is officially given "protected" status, will all future changes having to pass through CI in a pull request first.
Work begins on making profiles more clean-cut, less hairy:
- For simplicity, profiles are moved out of their public-suffix directories and into the main
profilesdirectory, with the full domain in the file name, as originally suggested in June. - The poorly-documented
profile.fields, only used in one profile, is dropped until it can get some proper thought and attention (see issue #6). - The
platformfield is dropped (along with its accompanying platform-profiles), under similar reasoning (see issue #5). - The
httpsfield documenting HTTPS support is also dropped, as there are tools that can give better automated analysis on-demand.
The template in CONTRIBUTING.md gains a reviewed.date example, replacing the now-removed https field.
Fields for session invalidation on password reset are added, and the values for password change are accordingly tweaked to match (with the "yes" value changing to the more-descriptive "own").
For consistency, email usability is changed to "single" and "double" instead of "once" and "twice".
A number of small details in password reset are encapsulated in the password.reset.steps structure described in issue #70. Extensions to this design continue for months, eventually expanding into issue #120 in May.
Three more issues proposing new fields are opened.
Issue #100, "Roadmap", is opened, calling for the creation of this very history document (among other things).
The name field is added to testing to be required on all profiles.
GitHub having introduced merge squashing as a feature for pull requests at the beginning of April, this is changed to be the new default for merging to master (with merge commits being disabled).
A proposal to basically convert password.reset into a structure resembling password.reset.steps (issue #120) is introduced. This consumes most thinking about structuring password reset profiling for the rest of the year.
The increasingly-hairy list-of-arbitrary-step-objects-to-represent-all-kinds-of-password-reset structure proposed in issue #120 is abandoned, in favor of a much more straightforward password.reset.flow structure, which only describes the most conventional kind of password reset, and more esoteric reset mechanisms (such as having a random password issued) going under different structures altogether, as described in issue #127.
password.reset.steps itself is reverted: different concerns are now split into different sub-fields with more information under password.reset.flow. Expiration, for instance, is refactored as an expire field on any step that can influence expiration.
stuartpb designates this as his Project of the Month for February 2017.
The project is moved out of the opensets organization and into a new dedicated "opws" organization, opws.org is registered, and the logo is drawn.
This history document is created to track the major movements in the project so far.
Every profile that has been written up to this point without a reviewed.date is scheduled to be reviewed over the course of February (portioned out to no more than five a day), so that the biggest blocking issue to the first numbered release can be resolved.
A lot of stuff happens. More than all project activity prior to February 2017 combined, in fact.