Difference between revisions of "Future Plans"

From GeeklogWiki
Jump to: navigation, search
 
(some status updates)
 
(18 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
= Things to consider for future releases =
 
= Things to consider for future releases =
  
== Geeklog 1.5.1 ==
+
== Clean up Remote Authentication ==
  
=== Clean up Remote Authentication ===
+
With the addition of [[OpenID]] and [[LDAP Remote Authentication|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:
 
  
 
* Duplicate email addresses
 
* Duplicate email addresses
 
* Missing email addresses
 
* Missing email addresses
 
* Ability to make remote users "local" users (and vice versa)
 
* 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, users.php, auth.inc.php)
* Need to clean up and unify / merge the login forms (side block and users.php)
+
* Ability to re-sync data with remote auth service, e.g. change of email address
* Support for OpenID 2.0 (Geeklog 1.5.0 supports OpenID 1.1)
+
* Clean up user preferences ("My Account") for remote users: Hide options that are not available (e.g. password change)
 +
* Also: [[SoC full openid support|Support for OpenID 2.0]] would be nice (Geeklog 1.5.0 supports OpenID 1.1)
 +
** Status: implemented as [[SoC full openid support|a GSoC project]] but not included into Geeklog yet
 +
 
 +
Some of these items are currently being worked on as part of [http://project.geeklog.net/tracking/view.php?id=1191 feature request #1191].
 +
 
  
=== Configuration ===
+
== 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.
  
 
* Re-ordering / re-grouping of options
 
* Re-ordering / re-grouping of options
* Ability to allow config access for certain user groups (currently requires Root access)
+
* Ability to allow config access for certain user groups (currently [http://project.geeklog.net/tracking/view.php?id=950 requires Root access] for everything)
 +
* Searching for a setting
 +
 
 +
Status: Implemented as [[SoC improve configuration gui|a GSoC project]] but not rolled into a Geeklog release yet.
 +
 
 +
 
 +
== Security ==
 +
 
 +
=== Passwords ===
 +
 
 +
It's about time we replace the md5 password hashes with something more modern and robust.
 +
 
 +
* Maybe use [http://www.openwall.com/phpass/ phpass]
 +
* To solve: What do we do with existing accounts?
 +
 
 +
==== WSSE ====
 +
 
 +
Somewhat related: If we wanted to support WSSE for the [[Webservices API#Authentication|Webservices]], we would either need to store the user's password in a way that's secure but reversible (so that we can get the unencrypted password for use in WSSE authentication) or think of a way to create a token / temp. password that the user can use in WSSE authentication.
 +
 
 +
==== HTTP Digest Authentication ====
 +
 
 +
Alternatively (instead of WSSE), if we wanted to support HTTP Digest Authentication, we would only have to keep track of the <tt>(user:realm:password)</tt> hash, probably as a separate field in the <tt>gl_users</tt> table, that needs to be updated whenever one of the three elements changes.
 +
 
 +
==== OAuth ====
 +
 
 +
Would [http://oauth.net/ OAuth] help? Also see [http://project.geeklog.net/tracking/view.php?id=1191 feature request #1191]
 +
 
 +
=== HTML filter ===
 +
 
 +
Since kses is no longer maintained, we need a replacement.
 +
 
 +
Requirements:
 +
* ??? (tbd)
 +
* [http://project.geeklog.net/tracking/view.php?id=1014 closing open HTML tags]?
 +
 
 +
Candidates:
 +
* [http://htmlpurifier.org/ HTML Purifier]
 +
* [http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/index.php htmLawed]
 +
 
 +
 
 +
== 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 <tt>Location:</tt> 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 <tt>Location:</tt> header.<br>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 (already used for "Unfortunately an error occured ..." - where else?)
 +
* Make use of <tt>Last-Modified:</tt> header (where is this actually possible?)
 +
 
 +
=== Microformats ===
  
 +
Somewhat related: Look into using (more) [http://microformats.org/ Microformats]
  
== Beyond 1.5.1 ==
 
  
* If we make it into the [[Google Summer of Code]] in 2008, there will probably be a release focussing on integrating the results
+
[[Category:Development]]

Latest revision as of 20:25, 29 October 2010

Things to consider for future releases

Clean up Remote Authentication

With the addition of OpenID and 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)
  • Need to clean up and unify / merge the login forms (side block, users.php, auth.inc.php)
  • Ability to re-sync data with remote auth service, e.g. change of email address
  • Clean up user preferences ("My Account") for remote users: Hide options that are not available (e.g. password change)
  • Also: Support for OpenID 2.0 would be nice (Geeklog 1.5.0 supports OpenID 1.1)
    • Status: implemented as a GSoC project but not included into Geeklog yet

Some of these items are currently being worked on as part of feature request #1191.


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)
  • Searching for a setting

Status: Implemented as a GSoC project but not rolled into a Geeklog release yet.


Security

Passwords

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?

WSSE

Somewhat related: If we wanted to support WSSE for the Webservices, we would either need to store the user's password in a way that's secure but reversible (so that we can get the unencrypted password for use in WSSE authentication) or think of a way to create a token / temp. password that the user can use in WSSE authentication.

HTTP Digest Authentication

Alternatively (instead of WSSE), if we wanted to support HTTP Digest Authentication, we would only have to keep track of the (user:realm:password) hash, probably as a separate field in the gl_users table, that needs to be updated whenever one of the three elements changes.

OAuth

Would OAuth help? Also see feature request #1191

HTML filter

Since kses is no longer maintained, we need a replacement.

Requirements:

Candidates:


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 (already used for "Unfortunately an error occured ..." - where else?)
  • Make use of Last-Modified: header (where is this actually possible?)

Microformats

Somewhat related: Look into using (more) Microformats