edemo / pdoauth Goto Github PK

• the user id shown for the same user is different for different applications
• the user id shown for a user to an application should not change over time
• the email address shown for the same user should be different for different applications
• there should be a database table mapping email addresses provided for applications and the email address given by the user such that major MTAs could use it for mail routing
• for each application there is a list of assurances used by that applications
• the applications receive intersection(user's assurances, application's assurances)
• the applications do not receive credential data from the user
• the applications do not receive the hash of the user
• the applications do not receive anything beyond mapped email address, mapped user id and filtered list of assurance names

For each of the hash entry fields it should be possible to use anchor to get the hash.

see BrowserSetup for a first stab at the needed infrastructure.
for chrome, you have to change ~/.pki/nssdb for different keysets.

the UI should use the logout functionality in #21

to use #6

the UIshould use the credential addon functionality in #27

The generated documentation should contain the version and the changelog obtained from git.

/logout should log the user out

the UI should use the credential removal functionality of #28

It should be possible to register and login for twitter.
We should make sure that Tompika can easily use our system, and learns how consultation should be done.

When served on https (as it should be), jquery does not load because it comes from a plain http uri.
The default make target should download the needed external components to ./static, and the static html should reference it from there.

--list-by-email listst the asurances for the user with the given email address
--list-by-assurance listst the users for the given assurance
--list-assurers is a shortcut for --list-by-assurance assurance.
--list-by-hash lists the assurances for the user with the given hash

registration and authentication should be possible using facebook

When the user is not logged in, there are possibilities for each of the login methods
- to login
- to register

When the user is logged in

• the login possibilities are hidden
• one logout possibility is shown depents on #21 #30
• a deregistration possibility is shown depends on #26 #31
• registration possibilities became "add credential for " . depends on #27 #32
• for each registered credentials - minus the one actually used - there is a clear possibility. depends on #28 #33

When a user tries to register/add a credential already existing for another user, it is offered to login as the other user and (deregister/clear the credential)/register the credential as the other user.

the UI should use the deregistration functionality in #26

It should be possible to generate an ssl certificate for authentication purposes.
See also #8

should be possible to get a password reset email with a password reset link

1.) It should be possible to record an ssl certificate fingerprint as a credential
2.) It should be possible to login using a certificate with the recorded fingerprint
See also #9

I am a new user trying to authenticate to one of the applications served by PDOauth.

I click the "login" button there, get redirected to pdoauth. When it turns out that I am not yet registered, I register, and the login process continues until I am able to login to the served application.

Integration test should confirm this behaviour.

Some error cases are not nicely handled in javascript.

it should be possible to unregister

Maybe an annotation could be created which names the screenshot file.
The screenshot function would take the filename from it.
The xslt could be modified to obtain the screenshot path from the annotation, and insert the picture.

the name of the annotation have changed...

Logging policy should be defined, and logging should be implemented according to that.

Sometimes there are multiple csrf cookies with different paths.

csrf cookie domain is set to the fqdn from BASE_URL
csrf cookie path is set to /

There is a heisenbug in the testing. It finds assurances for users who should not have one.
It is most probably related to collision of email addresses when testing model objects.

Például, ha kijelentkezel, amikor nem is vagy belépve

Using Archimate, so that a html document can be created and automated analysis of the architecture and its correlation with source code can be done.

• there is a SSL_LOGIN_BASE_URL config option containing the base url of the site with the optional_no_ca config
• there is a BASE_URL config option containing the plain ssl (no cert asked) base url
• there is a SSL_LOGOUT_URL config option pointing to a location which is set up with SSLVerifyClient require and SSLVerifyDepth 0 within SSL_LOGIN_BASE_URL
• there is a START_URL config option which contains the starting point useable for unregistered and/or not logged in user
• the unauthorized handler redirects to START_URL?next={request.url}
• the ssl login button on the UI redirects to the same url with BASE_URL changed to SSL_LOGIN_BASE_URL and hits ssl_login
• the logout button hits BASE_URL/logout, and leaves the user at START_URL

And html...

There should be a WordPress plugin which is able to use PDOauth.
To ensure that our implementation is standards compliand, it would be good if we could see that it works with an existing plugin.

1.) When an assurer wants to add an assurance for a user with hash and without email, and there are multiple users with that hash, then an error is signaled.
2.) When an assurance added with hash and email, and there is another user with the same hash, the hash from the other user is deleted.
3.) When a hash is registered which is already used by another user:
a) the user is notified about the fact
b) if the other user have non-automatic assurances (i.e. not emailverification), then the hash is not registered

when adding an assurance, hash should be sufficient to identify target user

It should be possible to register and login using google+

a user can clear its own credentials
the credential used for login cannot be cleared

A documentation site should be set up (maybe github.io), where the generated documentation gets refreshed in the travis build.

The unit test class names should be converted from camelcase to plain sentences.

There should be a password policy set, and enforced accross the application.

There are areas which are not tested deep enough. More tests - especially input validation ones - are welcome.

a logged in user can add credentials

It should be possible for an already registered user to record/chage the hash

• the user should be able to view the list of applications
• the application list should include for each application whether the user have ever logged in to it
• the user should be able to disable each application for herself
• if the application is disabled for the user, then if it asks for user info it will receive a message denoting it, and no user information
• if the application is disabled for the user, then the email address previously shown to the application for the user will be routed to /dev/null
• the user can discontinue disabling an application