Difference between revisions of "Future Plans"
From GeeklogWiki
("Service" column in user list) |
(Make better use of HTTP) |
||
| Line 1: | Line 1: | ||
= Things to consider for future releases = | = Things to consider for future releases = | ||
| − | + | == Clean up Remote Authentication == | |
| − | |||
| − | |||
With the addition of OpenID (and possibly LDAP) support in Geeklog 1.5.0, remote users will become more common and existing problems will become more apparent. For example: | With the addition of OpenID (and possibly LDAP) support in Geeklog 1.5.0, remote users will become more common and existing problems will become more apparent. For example: | ||
| Line 15: | Line 13: | ||
* Support for OpenID 2.0 (Geeklog 1.5.0 supports OpenID 1.1) | * Support for OpenID 2.0 (Geeklog 1.5.0 supports OpenID 1.1) | ||
| − | + | == Configuration == | |
The configuration GUI, introduced in Geeklog 1.5.0, will probably require adjustments once it's in widespread use, e.g. | The configuration GUI, introduced in Geeklog 1.5.0, will probably require adjustments once it's in widespread use, e.g. | ||
| Line 22: | Line 20: | ||
* Ability to allow config access for certain user groups (currently requires Root access for everything) | * Ability to allow config access for certain user groups (currently requires Root access for everything) | ||
| − | + | == Security == | |
It's about time we replace the md5 password hashes with something more modern and robust. | It's about time we replace the md5 password hashes with something more modern and robust. | ||
| Line 29: | Line 27: | ||
* To solve: What do we do with existing accounts? | * To solve: What do we do with existing accounts? | ||
| + | == Make better use of HTTP == | ||
| − | + | Sounds odd, but there's a lot of room in Geeklog to make better use of specific features of HTTP, especially HTTP status codes and additional HTTP headers. | |
| − | * | + | * HTTP status code 201: The proper response after creating something would be a 201 status code, accompanied by a Location: header pointing to the newly created resource. |
| + | * HTTP status code 303: When something has more than one URI, we should point the client to the preferred URI, using a 303 and a Location: header. Example: when URL rewriting is enabled and the request was for the "non-rewritten" URL. | ||
| + | * HTTP status codes 4xx and 5xx: In case of an error, we usually only display a human-readable error message, but send a 200 status code. There's a whole range of HTTP status codes that would make more sense to use, for example: | ||
| + | ** 400 Bad Request (invalid / incomplete data) | ||
| + | ** 403 Access denied (obvious; already used in some places) | ||
| + | ** 409 Conflict (e.g. when something already exists) | ||
| + | ** 500 Internal Server Errror (sounds like we should send that whenever we display "Unfortunately an error occured ...") | ||
Revision as of 07:45, 8 August 2008
Contents
Things to consider for future releases
Clean up Remote Authentication
With the addition of OpenID (and possibly LDAP) support in Geeklog 1.5.0, remote users will become more common and existing problems will become more apparent. For example:
- Duplicate email addresses
- Missing email addresses
- Ability to make remote users "local" users (and vice versa)
- Ability to entirely disable local logins
- Need to clean up and unify / merge the login forms (side block and users.php)
- Add a "service" column in the Admin's user list when remote auth is enabled to easily identify remote users and the service they're using
- Support for OpenID 2.0 (Geeklog 1.5.0 supports OpenID 1.1)
Configuration
The configuration GUI, introduced in Geeklog 1.5.0, will probably require adjustments once it's in widespread use, e.g.
- Re-ordering / re-grouping of options
- Ability to allow config access for certain user groups (currently requires Root access for everything)
Security
It's about time we replace the md5 password hashes with something more modern and robust.
- Maybe use phpass
- To solve: What do we do with existing accounts?
Make better use of HTTP
Sounds odd, but there's a lot of room in Geeklog to make better use of specific features of HTTP, especially HTTP status codes and additional HTTP headers.
- HTTP status code 201: The proper response after creating something would be a 201 status code, accompanied by a Location: header pointing to the newly created resource.
- HTTP status code 303: When something has more than one URI, we should point the client to the preferred URI, using a 303 and a Location: header. Example: when URL rewriting is enabled and the request was for the "non-rewritten" URL.
- HTTP status codes 4xx and 5xx: In case of an error, we usually only display a human-readable error message, but send a 200 status code. There's a whole range of HTTP status codes that would make more sense to use, for example:
- 400 Bad Request (invalid / incomplete data)
- 403 Access denied (obvious; already used in some places)
- 409 Conflict (e.g. when something already exists)
- 500 Internal Server Errror (sounds like we should send that whenever we display "Unfortunately an error occured ...")
