GNU MediaGoblin Wiki - User contributions [en]

HackingHowto

2013-07-02T18:55:31Z

Rodney757: /* Mac OS X Lion */

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at [http://docs.mediagoblin.org/devel/codebase.html codebase chapter] where
we've started documenting how GNU MediaGoblin is built and how to add
new things. If you're planning on contributing in python, you should be aware
of [http://www.python.org/dev/peps/pep-0008/ PEP-8], the official Python style guide,
which we follow.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use an
in-package checkout of virtualenv. This isn't the convenional way to
install virtualenv (normally you don't install virtualenv inside the
package itself) but we've found that it's significantly easier for
newcomers who aren't already familiar with virtualenv. If you *are*
already familiar with virtualenv, feel free to just install
mediagoblin in your own virtualenv setup... the necessary adjustments
should be obvious.

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* SQLAlchemy 0.7.0 or higher - http://www.sqlalchemy.org/
* Python Imaging Library (PIL) - http://www.pythonware.com/products/pil/
* virtualenv - http://www.virtualenv.org/
* Python GStreamer Bindings - http://gstreamer.freedesktop.org/modules/gst-python.html

=== GNU/Linux ===

==== Debian and derivatives ====

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

{{Cmd|sudo apt-get install git-core python python-dev python-lxml python-imaging python-virtualenv python-gst0.10 libjpeg8-dev}}

==== Fedora / RedHat(?) ====

On Fedora:

{{Cmd|yum install python-paste-deploy python-paste-script git-core python python-devel python-lxml python-imaging python-virtualenv gstreamer-python}}

=== Mac OS X ===

==== Mac OS X Lion ====

Download the Newest Python.

Git is already installed.

* Note for PIL and lxml, you can: pip install pil lxml

Python-lxml: http://muffinresearch.co.uk/archives/2009/03/05/install-lxml-on-osx/ with sudo

Python Imaging Library (PIL): http://code.google.com/appengine/docs/python/images/installingPIL.html#mac

Libjpeg & Libpng: http://ethan.tira-thompson.com/Mac_OS_X_Ports.html Combo Installer

==== Mac OS X Snow Leopard ====

# You will probably want to install MacPorts this will give you access to many free software packages in the same manner to apt-get and yum: https://www.macports.org/install.php
# Ensure you install Git and the command line tools: https://help.github.com/articles/set-up-git#platform-mac
# Once both of those are installed type this in your terminal and enter your password when prompted for it {{Cmd|sudo port install python27 py27-lxml py27-sqlalchemy py27-pil py27-virtualenv py27-gst-python py27-pastescript}}

=== Microsoft Windows ===

''Thanks wctype!''

==== Getting requirements ====

* Python 2.7 - [http://www.python.org/download/ Download] 
* git - [https://github.com/msysgit/git/downloads Download] 
* python-lxml - [http://pypi.python.org/pypi/lxml/2.3.5#downloads Tarball] [http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil Binaries] 
* Python Imaging Library (PIL) - [http://www.pythonware.com/products/pil/ Download] 
* virtualenv - [http://pypi.python.org/pypi/virtualenvwrapper-win/1.0.8#downloads Download] 
* OSSBuild project provides reasonably up-to-date binaries of GStreamer - [https://code.google.com/p/ossbuild/downloads/list Download] 
* py-bcrypt - [https://bitbucket.org/alexandrul/py-bcrypt/downloads/ Download] 

----

'''You can help:'''

If you have instructions for other GNU/Linux distributions, Windows, or Mac OS X to set
up requirements, [http://mediagoblin.org/join/ let us know]!

== How to set up and maintain an environment for hacking with virtualenv ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

* Clone the repository: {{Cmd|git clone <nowiki>git://gitorious.org/mediagoblin/mediagoblin.git</nowiki>}}
* Change directories to your new checkout: {{Cmd|cd mediagoblin}}
* Checkout git submodules: {{Cmd|git submodule init}} {{Cmd|git submodule update}}
* Set up the in-package virtualenv:
(virtualenv --system-site-packages . || virtualenv .)
* Run setup.py:
{{Cmd|./bin/python setup.py develop}}
* Init the database:
{{Cmd|./bin/gmg dbupdate}}

That's it!

(If you have troubles in the remaining steps, consider try installing
virtualenv with one of the flags --setuptools, --distribute or possibly --no-site-packages. Additionally, if your system has python3.X as the default, you might need to do virtualenv --python=python2.7 or --python=python2.6)

If you have problems, please [http://mediagoblin.org/join/ let us know]!

== Updating an existing environment ==

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed.

To do that, run:

{{Cmd|./bin/python setup.py develop --upgrade && ./bin/gmg dbupdate}}

'''Updating for code changes'''

{{Cmd|git pull -u}}
{{Cmd|git submodule update}}

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

{{Cmd|./lazyserver.sh}}

This will start up a python server where you can begin playing with
mediagoblin, listening on 127.0.0.1:6543. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

By default, the instance is not sending out confirmation mails. Instead they are redirected to the standard output (the console) of lazyserver.sh.

You can change this behavior setting <code>email_debug_mode</code> to <code>false</code> in mediagoblin.ini

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

{{Cmd|./bin/paster serve paste.ini --reload}}

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

{{Cmd|<nowiki>CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd</nowiki>}}

== Running the test suite ==

Run:

{{Cmd|./runtests.sh}}

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

{{Cmd|./bin/gmg shell}}

== Troubleshooting ==

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

{{Cmd|rm -rf mediagoblin.db kombu.db celery.db user_dev; ./bin/gmg dbupdate}}

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has SQLAlchemy ORM definitions
* <tt>views.py</tt> is where the views go

We're using SQLAlchemy, which is semi-similar to the Django ORM, but
not really because you can get a lot more fine-grained. The
[http://docs.sqlalchemy.org/en/latest/orm/tutorial.html SQLAlchemy ORM tutorial] is a great place to start.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Showing off your work with PageKite ==

If you're doing development with MediaGoblin, it's sometimes helpful to show off your work to gather feedback from other contributors. A number of the MediaGoblin developers use something called [http://pagekite.net PageKite], which is a fellow free software web service which makes temporarily showing off work on your machine easy. There's a [http://pagekite.net/wiki/Howto/UsePageKiteWithMediaGoblin/ tutorial on how to use PageKite and MediaGoblin together] available on the PageKite wiki.

If you are doing a lot of MediaGoblin development, the PageKite people have graciously offered us a good amount of bandwidth at no cost in an effort to help out fellow free software projects. If you've been making significant contributions, PM Chris Webber on freenode (who is paroneayea there) and ask if you can be added to our group plan.

== Bite-sized bugs to start with ==

Now you should visit our latest list of [http://issues.mediagoblin.org/query?status=!closed&keywords=~bitesized bite-sized issues] because squishing bugs is messy fun. If you're interested in other things to work on, or need help getting started on a bug, let us know on [http://mediagoblin.org/join/ the mailing list] or on the [http://mediagoblin.org/join/ IRC channel].

HackingHowto

2013-06-22T17:43:17Z

Rodney757: /* Mac OS X Lion */

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at [http://docs.mediagoblin.org/devel/codebase.html codebase chapter] where
we've started documenting how GNU MediaGoblin is built and how to add
new things. If you're planning on contributing in python, you should be aware
of [http://www.python.org/dev/peps/pep-0008/ PEP-8], the official Python style guide,
which we follow.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use an
in-package checkout of virtualenv. This isn't the convenional way to
install virtualenv (normally you don't install virtualenv inside the
package itself) but we've found that it's significantly easier for
newcomers who aren't already familiar with virtualenv. If you *are*
already familiar with virtualenv, feel free to just install
mediagoblin in your own virtualenv setup... the necessary adjustments
should be obvious.

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* SQLAlchemy 0.7.0 or higher - http://www.sqlalchemy.org/
* Python Imaging Library (PIL) - http://www.pythonware.com/products/pil/
* virtualenv - http://www.virtualenv.org/
* Python GStreamer Bindings - http://gstreamer.freedesktop.org/modules/gst-python.html

=== GNU/Linux ===

==== Debian and derivatives ====

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

{{Cmd|sudo apt-get install git-core python python-dev python-lxml python-imaging python-virtualenv python-gst0.10 libjpeg8-dev}}

==== Fedora / RedHat(?) ====

On Fedora:

{{Cmd|yum install python-paste-deploy python-paste-script git-core python python-devel python-lxml python-imaging python-virtualenv gstreamer-python}}

=== Mac OS X ===

==== Mac OS X Lion ====

Download the Newest Python.

Git is already installed.

* Note for PIL and lxml, you can: pip install pil lxml

Python-lxml: http://muffinresearch.co.uk/archives/2009/03/05/install-lxml-on-osx/ with sudo

Python Imaging Library (PIL): http://code.google.com/appengine/docs/python/images/installingPIL.html#mac

Libjpeg & Libpng: http://ethan.tira-thompson.org/Mac_OS_X_Ports.html Combo Installer

==== Mac OS X Snow Leopard ====

# You will probably want to install MacPorts this will give you access to many free software packages in the same manner to apt-get and yum: https://www.macports.org/install.php
# Ensure you install Git and the command line tools: https://help.github.com/articles/set-up-git#platform-mac
# Once both of those are installed type this in your terminal and enter your password when prompted for it {{Cmd|sudo port install python27 py27-lxml py27-sqlalchemy py27-pil py27-virtualenv py27-gst-python py27-pastescript}}

=== Microsoft Windows ===

''Thanks wctype!''

==== Getting requirements ====

* Python 2.7 - [http://www.python.org/download/ Download] 
* git - [https://github.com/msysgit/git/downloads Download] 
* python-lxml - [http://pypi.python.org/pypi/lxml/2.3.5#downloads Tarball] [http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil Binaries] 
* Python Imaging Library (PIL) - [http://www.pythonware.com/products/pil/ Download] 
* virtualenv - [http://pypi.python.org/pypi/virtualenvwrapper-win/1.0.8#downloads Download] 
* OSSBuild project provides reasonably up-to-date binaries of GStreamer - [https://code.google.com/p/ossbuild/downloads/list Download] 
* py-bcrypt - [https://bitbucket.org/alexandrul/py-bcrypt/downloads/ Download] 

----

'''You can help:'''

If you have instructions for other GNU/Linux distributions, Windows, or Mac OS X to set
up requirements, [http://mediagoblin.org/join/ let us know]!

== How to set up and maintain an environment for hacking with virtualenv ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

* Clone the repository: {{Cmd|git clone <nowiki>git://gitorious.org/mediagoblin/mediagoblin.git</nowiki>}}
* Change directories to your new checkout: {{Cmd|cd mediagoblin}}
* Checkout git submodules: {{Cmd|git submodule init}} {{Cmd|git submodule update}}
* Set up the in-package virtualenv:
(virtualenv --system-site-packages . || virtualenv .)
* Run setup.py:
{{Cmd|./bin/python setup.py develop}}
* Init the database:
{{Cmd|./bin/gmg dbupdate}}

That's it!

(If you have troubles in the remaining steps, consider try installing
virtualenv with one of the flags --setuptools, --distribute or possibly --no-site-packages. Additionally, if your system has python3.X as the default, you might need to do virtualenv --python=python2.7 or --python=python2.6)

If you have problems, please [http://mediagoblin.org/join/ let us know]!

== Updating an existing environment ==

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed.

To do that, run:

{{Cmd|./bin/python setup.py develop --upgrade && ./bin/gmg dbupdate}}

'''Updating for code changes'''

{{Cmd|git pull -u}}
{{Cmd|git submodule update}}

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

{{Cmd|./lazyserver.sh}}

This will start up a python server where you can begin playing with
mediagoblin, listening on 127.0.0.1:6543. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

By default, the instance is not sending out confirmation mails. Instead they are redirected to the standard output (the console) of lazyserver.sh.

You can change this behavior setting <code>email_debug_mode</code> to <code>false</code> in mediagoblin.ini

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

{{Cmd|./bin/paster serve paste.ini --reload}}

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

{{Cmd|<nowiki>CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd</nowiki>}}

== Running the test suite ==

Run:

{{Cmd|./runtests.sh}}

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

{{Cmd|./bin/gmg shell}}

== Troubleshooting ==

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

{{Cmd|rm -rf mediagoblin.db kombu.db celery.db user_dev; ./bin/gmg dbupdate}}

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has SQLAlchemy ORM definitions
* <tt>views.py</tt> is where the views go

We're using SQLAlchemy, which is semi-similar to the Django ORM, but
not really because you can get a lot more fine-grained. The
[http://docs.sqlalchemy.org/en/latest/orm/tutorial.html SQLAlchemy ORM tutorial] is a great place to start.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Showing off your work with PageKite ==

If you're doing development with MediaGoblin, it's sometimes helpful to show off your work to gather feedback from other contributors. A number of the MediaGoblin developers use something called [http://pagekite.net PageKite], which is a fellow free software web service which makes temporarily showing off work on your machine easy. There's a [http://pagekite.net/wiki/Howto/UsePageKiteWithMediaGoblin/ tutorial on how to use PageKite and MediaGoblin together] available on the PageKite wiki.

If you are doing a lot of MediaGoblin development, the PageKite people have graciously offered us a good amount of bandwidth at no cost in an effort to help out fellow free software projects. If you've been making significant contributions, PM Chris Webber on freenode (who is paroneayea there) and ask if you can be added to our group plan.

== Bite-sized bugs to start with ==

Now you should visit our latest list of [http://issues.mediagoblin.org/query?status=!closed&keywords=~bitesized bite-sized issues] because squishing bugs is messy fun. If you're interested in other things to work on, or need help getting started on a bug, let us know on [http://mediagoblin.org/join/ the mailing list] or on the [http://mediagoblin.org/join/ IRC channel].

Authentication

2013-05-06T14:25:03Z

Rodney757: /* basic_auth: */

== Different use cases for different login systems ==

Different login systems may affect the way auth stuff works differently. For example, all of these cases are very different, but all fall under the "auth world view":

* You log in via some central auth system thing that uses the mediagoblin login page interface, but passes off the username/password to some other database. (If that username and password exist remotely, do we need to "give" that username to a newly created user?)
* Persona/OpenID style: You have a user, but you have the option to log in the user via some external page and then come back. In this case, we're probably not creating new users on-demand, and we don't really use the login page at all anyway.

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This is the way we are going to implement auth plugins.

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
mediagoblin.ini:<nowiki>
[plugins]
[[plugins.ldap]]
[[[server1]]]
[[[server2]]]

auth/__init__.py:
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)

auth_plugin/__init__.py:
...
hooks = {"auth_check_login": check_login}
# or depending on the plugin
def setup_plugin():
serv1 = ldap_thing(config1)
serv2 = ldap_thing(config2)
pluginapi.add_hook("check_login", serv1.check_login)
pluginapi.add_hook("check_login", serv2.check_login)
...

def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

==Various ideas on how to use classy authentication providers with the hooky authentication system==

<nowiki>
...
class LDAPLoginer():
pass

for ldap_config in ldap_configs:
my_ldap = LDAPLoginer(ldap_config)
add_hook('login': my_ldap.login)
...

...
def add_classy_hooks(cls, hook_list):
q = {}
for h in hook_list:
q[h] = getattr(cls, h)
pluginapi.add_hooks_dict(q)

for ldap_config in ldap_configs:
ldap = LDAPAuth(ldap_config)
add_classy_hooks(ldap, ['check_login'])
...</nowiki>

== Proposed DB Schema ==

Would remove pw_hash from User model. Reason is if someone would like to have the only way to login to an account is with OpenID or Persona. We would still require every account to have a unique username regardless of the Authentication enabled, thus username will be left in the User model. Email would be left in the User model for the same reason as username.

===OpenID/Persona:===

openid_url = Column(unicode, nullable=False)

user = Column(Integer, ForeignKey(User,id), nullable=False)

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-06T00:45:42Z

Rodney757: /* Proposed DB Schema */

== Different use cases for different login systems ==

Different login systems may affect the way auth stuff works differently. For example, all of these cases are very different, but all fall under the "auth world view":

* You log in via some central auth system thing that uses the mediagoblin login page interface, but passes off the username/password to some other database. (If that username and password exist remotely, do we need to "give" that username to a newly created user?)
* Persona/OpenID style: You have a user, but you have the option to log in the user via some external page and then come back. In this case, we're probably not creating new users on-demand, and we don't really use the login page at all anyway.

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This is the way we are going to implement auth plugins.

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
mediagoblin.ini:<nowiki>
[plugins]
[[plugins.ldap]]
[[[server1]]]
[[[server2]]]

auth/__init__.py:
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)

auth_plugin/__init__.py:
...
hooks = {"auth_check_login": check_login}
# or depending on the plugin
def setup_plugin():
serv1 = ldap_thing(config1)
serv2 = ldap_thing(config2)
pluginapi.add_hook("check_login", serv1.check_login)
pluginapi.add_hook("check_login", serv2.check_login)
...

def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

==Various ideas on how to use classy authentication providers with the hooky authentication system==

<nowiki>
...
class LDAPLoginer():
pass

for ldap_config in ldap_configs:
my_ldap = LDAPLoginer(ldap_config)
add_hook('login': my_ldap.login)
...

...
def add_classy_hooks(cls, hook_list):
q = {}
for h in hook_list:
q[h] = getattr(cls, h)
pluginapi.add_hooks_dict(q)

for ldap_config in ldap_configs:
ldap = LDAPAuth(ldap_config)
add_classy_hooks(ldap, ['check_login'])
...</nowiki>

== Proposed DB Schema ==

Would remove pw_hash from User model. Reason is if someone would like to have the only way to login to an account is with OpenID or Persona. We would still require every account to have a unique username regardless of the Authentication enabled, thus username will be left in the User model. Email would be left in the User model for the same reason as username.

===basic_auth:===

pw_hash = Column(Unicode, nullable=False)

user = Column(Integer, ForeignKey(User.id), nullable=False)

===OpenID/Persona:===

openid_url = Column(unicode, nullable=False)

user = Column(Integer, ForeignKey(User,id), nullable=False)

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-06T00:31:30Z

Rodney757: /* basic_auth */

== Different use cases for different login systems ==

Different login systems may affect the way auth stuff works differently. For example, all of these cases are very different, but all fall under the "auth world view":

* You log in via some central auth system thing that uses the mediagoblin login page interface, but passes off the username/password to some other database. (If that username and password exist remotely, do we need to "give" that username to a newly created user?)
* Persona/OpenID style: You have a user, but you have the option to log in the user via some external page and then come back. In this case, we're probably not creating new users on-demand, and we don't really use the login page at all anyway.

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This is the way we are going to implement auth plugins.

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
mediagoblin.ini:<nowiki>
[plugins]
[[plugins.ldap]]
[[[server1]]]
[[[server2]]]

auth/__init__.py:
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)

auth_plugin/__init__.py:
...
hooks = {"auth_check_login": check_login}
# or depending on the plugin
def setup_plugin():
serv1 = ldap_thing(config1)
serv2 = ldap_thing(config2)
pluginapi.add_hook("check_login", serv1.check_login)
pluginapi.add_hook("check_login", serv2.check_login)
...

def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

==Various ideas on how to use classy authentication providers with the hooky authentication system==

<nowiki>
...
class LDAPLoginer():
pass

for ldap_config in ldap_configs:
my_ldap = LDAPLoginer(ldap_config)
add_hook('login': my_ldap.login)
...

...
def add_classy_hooks(cls, hook_list):
q = {}
for h in hook_list:
q[h] = getattr(cls, h)
pluginapi.add_hooks_dict(q)

for ldap_config in ldap_configs:
ldap = LDAPAuth(ldap_config)
add_classy_hooks(ldap, ['check_login'])
...</nowiki>

== Proposed DB Schema ==

===basic_auth===

pw_hash = Column(Unicode, nullable=False)
user = Column(Integer, ForeignKey(User.id), nullable=False)

===openid/persona===

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-06T00:16:58Z

Rodney757: /* __init__.py Base Class */

== Different use cases for different login systems ==

Different login systems may affect the way auth stuff works differently. For example, all of these cases are very different, but all fall under the "auth world view":

* You log in via some central auth system thing that uses the mediagoblin login page interface, but passes off the username/password to some other database. (If that username and password exist remotely, do we need to "give" that username to a newly created user?)
* Persona/OpenID style: You have a user, but you have the option to log in the user via some external page and then come back. In this case, we're probably not creating new users on-demand, and we don't really use the login page at all anyway.

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This is the way we are going to implement auth plugins.

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
mediagoblin.ini:<nowiki>
[plugins]
[[plugins.ldap]]
[[[server1]]]
[[[server2]]]

auth/__init__.py:
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)

auth_plugin/__init__.py:
...
hooks = {"auth_check_login": check_login}
# or depending on the plugin
def setup_plugin():
serv1 = ldap_thing(config1)
serv2 = ldap_thing(config2)
pluginapi.add_hook("check_login", serv1.check_login)
pluginapi.add_hook("check_login", serv2.check_login)
...

def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

==Various ideas on how to use classy authentication providers with the hooky authentication system==

<nowiki>
...
class LDAPLoginer():
pass

for ldap_config in ldap_configs:
my_ldap = LDAPLoginer(ldap_config)
add_hook('login': my_ldap.login)
...

...
def add_classy_hooks(cls, hook_list):
q = {}
for h in hook_list:
q[h] = getattr(cls, h)
pluginapi.add_hooks_dict(q)

for ldap_config in ldap_configs:
ldap = LDAPAuth(ldap_config)
add_classy_hooks(ldap, ['check_login'])
...</nowiki>

== Proposed DB Schema ==

===basic_auth===

===openid/persona===

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-03T16:12:49Z

Rodney757: /* __init__.py Base Class */

== Different use cases for different login systems ==

Different login systems may affect the way auth stuff works differently. For example, all of these cases are very different, but all fall under the "auth world view":

* You log in via some central auth system thing that uses the mediagoblin login page interface, but passes off the username/password to some other database. (If that username and password exist remotely, do we need to "give" that username to a newly created user?)
* Persona/OpenID style: You have a user, but you have the option to log in the user via some external page and then come back. In this case, we're probably not creating new users on-demand, and we don't really use the login page at all anyway.

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This is the way we are going to implement auth plugins.

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
mediagoblin.ini:<nowiki>
[plugins]
[[plugins.ldap]]
[[[server1]]]
[[[server2]]]

auth/__init__.py:
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)

auth_plugin/__init__.py:
...
hooks = {"auth_check_login": check_login}
# or depending on the plugin
def setup_plugin():
serv1 = ldap_thing(config1)
serv2 = ldap_thing(config2)
pluginapi.add_hook("check_login", serv1.check_login)
pluginapi.add_hook("check_login", serv2.check_login)
...

def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

==Various ideas on how to use classy authentication providers with the hooky authentication system==

<nowiki>
...
class LDAPLoginer():
pass

for ldap_config in ldap_configs:
my_ldap = LDAPLoginer(ldap_config)
add_hook('login': my_ldap.login)
...

...
def add_classy_hooks(cls, hook_list):
q = {}
for h in hook_list:
q[h] = getattr(cls, h)
pluginapi.add_hooks_dict(q)

for ldap_config in ldap_configs:
ldap = LDAPAuth(ldap_config)
add_classy_hooks(ldap, ['check_login'])
...</nowiki>

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-03T14:23:03Z

Rodney757: /* Non-Interfacey Design w/ hooks for every call: */

== Different use cases for different login systems ==

Different login systems may affect the way auth stuff works differently. For example, all of these cases are very different, but all fall under the "auth world view":

* You log in via some central auth system thing that uses the mediagoblin login page interface, but passes off the username/password to some other database. (If that username and password exist remotely, do we need to "give" that username to a newly created user?)
* Persona/OpenID style: You have a user, but you have the option to log in the user via some external page and then come back. In this case, we're probably not creating new users on-demand, and we don't really use the login page at all anyway.

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This is the way we are going to implement auth plugins.

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
mediagoblin.ini:<nowiki>
[plugins]
[[plugins.ldap]]
[[[server1]]]
[[[server2]]]

auth/__init__.py:
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)

auth_plugin/__init__.py:
...
hooks = {"auth_check_login": check_login}
# or depending on the plugin
def setup_plugin():
serv1 = ldap_thing(config1)
serv2 = ldap_thing(config2)
pluginapi.add_hook("check_login", serv1.check_login)
pluginapi.add_hook("check_login", serv2.check_login)
...

def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-02T20:10:07Z

Rodney757: /* Non-Interfacey Design w/ hooks for every call: */

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
auth/__init__.py:<nowiki>
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)

auth_plugin/__init__.py:
hooks = {"auth_check_login": check_login}
def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-02T20:09:39Z

Rodney757: /* Interfacey Design w/ hooks: */

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
auth/__init__.py:<nowiki>
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_check_login": check_login}
def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-02T20:08:51Z

Rodney757: /* Interfacey Design w/o hooks: */

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function, *args):
for p in _auth_providers:
response = p.function(*args)
if response:
return response
raise NotImplemented("No provider for %s" % functions)

def check_login(self, user, password):
return get_response("check_login", user, password)

auth_plugin/__init__.py:
def setup_plugin():
add_auth_provider(SomeAuthPlugin(config1))
add_auth_provider(SomeAuthPlugin(config2))</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Plugins can configure the individual instance (ldap server name)
* Plugins can instantiate multiple providers for different backends, like two different ldap servers

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface. Basicly a variation on the previous idea, just a bit more "hooky".

Ex:
auth/__init__.py:<nowiki>
...
def setup_auth():
global _auth_providers
_auth_providers += hook_runall("auth_provider")
...

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_provider": get_auth_provider}
def get_auth_provider(): return AuthUserInterface()</nowiki>

====Pros====
* Plugins could inherit from another plugin and override.
* Still allows configuration on the individual instance

====Cons====
* would basically be duplicating the code for hook_handle
* No easy way to add multiple instances of one Provider

===Non-Interfacey Design w/ hooks for every call:===

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
auth/__init__.py:<nowiki>
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_check_login": check_login}
def check_login(user, password):
if a: return True # Yes, let them in
if b: return False # No and don't try other providers
return None # Don't know, try next provider.</nowiki>

====Pros====

* Simpler to implement

====Cons====

All the Pros from the interface design are not here:
* config data has to be global on the plugin, not local to the instantiated provider
* No straight way of doing multiple instances.
*: Yes, the individual hook could do it by itself

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-02T19:27:22Z

Rodney757:

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

def get_response(function(*args)):
for p in _auth_providers:
response = p.function(*args)

class AuthUserInterface(object):

def check_login(self, user, password):
response = get_response(check_login(user, password))
if response:
return response
raise NotImplementedError</nowiki>

auth_plugin/__init__.py:<nowiki>
def setup_plugin():
add_auth_provider(AuthPluginInterface())</nowiki>

====Pros====

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface.

Ex:
auth/__init__.py:<nowiki>
def setup_auth():
global _auth_providers
_auth_providers = hook_runall("auth_provider")

def get_response(function(*args)):
for p in _auth_providers:
response = p.function(*args)

class AuthUserInterface(object):

def check_login(self, user, password):
response = get_response(check_login(user, password))
if response:
return response
raise NotImplementedError</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_provider": AuthUserInterface()}</nowiki>

====Pros====

====Cons====

* would basically be duplicating the code for hook_handle

===Non-Interfacey Design w/ hooks for every call:===

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
auth/__init__.py:<nowiki>
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_check_login": check_login</nowiki>

====Pros====

* Simpler to implement

====Cons====

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-02T19:26:07Z

Rodney757: /* Interfacey Design w/ hooks: */

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

class AuthUserInterface(object):

def check_login(self, user, password):
for p in _auth_providers:
res = p.check_login(user, password)
if res:
return res
raise NotImplementedError</nowiki>

auth_plugin/__init__.py:<nowiki>
def setup_plugin():
add_auth_provider(AuthPluginInterface())</nowiki>

====Pros====

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface.

Ex:
auth/__init__.py:<nowiki>
def setup_auth():
global _auth_providers
_auth_providers = hook_runall("auth_provider")

def get_response(function(*args)):
for p in _auth_providers:
response = p.function(*args)

class AuthUserInterface(object):

def check_login(self, user, password):
response = get_response(check_login(user, password))
if response:
return response
raise NotImplementedError</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_provider": AuthUserInterface()}</nowiki>

====Pros====

====Cons====

* would basically be duplicating the code for hook_handle

===Non-Interfacey Design w/ hooks for every call:===

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
auth/__init__.py:<nowiki>
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_check_login": check_login</nowiki>

====Pros====

* Simpler to implement

====Cons====

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-02T19:25:36Z

Rodney757: /* Interfacey Design w/ hooks: */

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

class AuthUserInterface(object):

def check_login(self, user, password):
for p in _auth_providers:
res = p.check_login(user, password)
if res:
return res
raise NotImplementedError</nowiki>

auth_plugin/__init__.py:<nowiki>
def setup_plugin():
add_auth_provider(AuthPluginInterface())</nowiki>

====Pros====

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface.

Ex:
auth/__init__.py:<nowiki>
def setup_auth():
global _auth_providers
_auth_providers = hook_runall("auth_provider")

def get_response(function(*args)):
for p in _auth_providers:
response = p.function(*args)

class AuthUserInterface(object):

def check_login(self, user, password):
response = get_response(check_login(user, password)
if response:
return response
raise NotImplementedError</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_provider": AuthUserInterface()}</nowiki>

====Pros====

====Cons====

* would basically be duplicating the code for hook_handle

===Non-Interfacey Design w/ hooks for every call:===

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
auth/__init__.py:<nowiki>
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_check_login": check_login</nowiki>

====Pros====

* Simpler to implement

====Cons====

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-02T18:58:39Z

Rodney757: /* Auth Plugin Design Pros/Cons */

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

===Interfacey Design w/o hooks:===

Using an interface design similar to the Base Class design below. Calls would be added to _auth_providers list in the dummy class when setup_plugin is run. Each function in the dummy class would run through the _auth_providers list and return the response from the corresponding function from the last plugin in _auth_providers list.

Ex:
auth/__init__.py:<nowiki>
_auth_providers = []
def add_auth_provider(provider):
_auth_providers.append(provider)

class AuthUserInterface(object):

def check_login(self, user, password):
for p in _auth_providers:
res = p.check_login(user, password)
if res:
return res
raise NotImplementedError</nowiki>

auth_plugin/__init__.py:<nowiki>
def setup_plugin():
add_auth_provider(AuthPluginInterface())</nowiki>

====Pros====

====Cons====

*basically be duplicating the code for hook_handle

===Interfacey Design w/ hooks:===

Using an interface design similar to the Base Class design below and using hooks to register the auth_plugin interface.

Ex:
auth/__init__.py:<nowiki>
def setup_auth():
global _auth_providers
_auth_providers = hook_runall("auth_provider")

class AuthUserInterface(object):

def check_login(self, user, password):
for p in _auth_providers:
res = p.check_login(user, password)
if res:
return res
raise NotImplementedError</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_provider": AuthUserInterface()}</nowiki>

====Pros====

====Cons====

* would basically be duplicating the code for hook_handle

===Non-Interfacey Design w/ hooks for every call:===

This design would have a plugin "template" in auth/__init__.py similar to the Interfacey designs, except that it would use hook_handle() for each function.

Ex.
auth/__init__.py:<nowiki>
def check_login(user, Password):
return hook_handle("auth_check_login", user, password)</nowiki>

auth_plugin/__init__.py:<nowiki>
hooks = {"auth_check_login": check_login</nowiki>

====Pros====

* Simpler to implement

====Cons====

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Authentication

2013-05-02T18:22:14Z

Rodney757:

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== Auth Plugin Design Pros/Cons ==

Interfacey Design w/o hooks:

<nowiki>Place holder
</nowiki>

Interfacey Design w/ hooks:

<nowiki>Insert non-formatted text here</nowiki>

Non-Interfacey Design w/ hooks for every call:

<nowiki>Insert non-formatted text here</nowiki>

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

Meeting

2013-05-02T18:09:09Z

Rodney757: /* Next Meeting */

== MediaGoblin Monthly Meeting ==

'''When:''' 9:00 am Pacific Time first Saturday of the month. [http://www.timeanddate.com/worldclock/converter.html Convert time to your timezone]. Print current UTC time: <code>date -u +"It's %F %T UTC"</code>

'''Where:''' IRC #mediagoblin on irc.freenode.net

Always announced several days in advance on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list] as is date adjustments, agenda discussion and other meeting preparation.

'''Purpose:''' The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

Typical Agenda topics:

* What happened in the last month, what was good, what could be better next time?
* What should be done next month?

Meetings are logged. [http://mediagoblin.org/irclogs/ Logs for past meetings.]

== Next Meeting ==

[[meeting-2013-05-04|May 4th, 2013, 9:00 am Pacific Time (2013-05-04 16:00 UTC)]]

* GSOC and Gnome Outreach for Women participation update
* Mention the bug triage meeting
* Improving our unit tests?
* 0.4.0 release coming soon
* Help review code?

== Past Meetings ==

=== April 6, 2013, 9:00 am Pacific Time (2013-03-30 16:00 UTC) ===

* Plugins update
* Post-libreplanet sprint merging
* Gstreamer 1.0 stuff (if Joar is here!)
* GSOC and Gnome Outreach for Women participation
* ???

=== March 2nd, 2013, 9:00 am Pacific Time (2013-03-02 16:00 UTC) ===

* Bug triage day discussion
* Upgrading Trac to 1.0
* Next release: 0.3.3
* Consider have release dates?
* Plugin stystem
* Consider moving to GStreamer 1.0
** Debian - 1.0 in sid
** Ubuntu - 1.0 in 12.10
*** Possibly backports for 12.04
** Fedora - 1.0 in 18
* Upcoming conferences and hackathons

=== February 9th, 2013, 9:00 am Pacific Time (2013-02-09 16:00 UTC) ===

* 0.3.3 milestone! What about our next release? :)
* Where to put Developer docs?
*: Our Documentation for developers is currently a bit split. Some are on the wiki, some in the main docs. There are pros and cons for both. We should consider where to put things. One place? Which? Or decide on an individual basis?
*: Good about main docs: Easy to integrate source code doc strings. That way internal api docs can be kept mostly up to date.
*: Good about wiki: Doesn't feel so "set in stone".
* wiki spam: Do we want to change something?
* [http://lists.mediagoblin.org/pipermail/devel/2012-November/000307.html Designing features!]
* Plugins, and architecting for plugins
* Chris Webber gives updates on how he's settling into his role ;)

=== October 13th, 2012, 9:00 am Pacific Time (2012-10-13 16:00 UTC) ===

* 0.3.2 release
** What existing features need to be wrapped up?
*** Werkzeug switch
** What time might we do the release?
* Fundraising campaign
** Keeping things going mid-campaign
** You have questions? I have answers, kinda :)
* Getting new contributors involved
* Plugins? New features?

==== Etherpad ====
<pre>
AGENDA

0.3.2 release

What existing features need to be wrapped up?

Werkzeug switch

What time might we do the release?

Congrats to Deb from the mediagoblin team! Congrats de Deb!

Fundraising campaign

Keeping things going mid-campaign

You have questions? I have answers, kinda :)

Getting new contributors involved

Plugins? New features?

-- http://wiki.mediagoblin.org/Meeting#Next_Meeting
Fundraising stuff
Things are going great mostly when people check it out!
But how to spread the word?

should contact more podcasts, etc

currently working with FSF on this

need community to spread the word!

List of places already spreaded list and contacted

VideoThumbnailerMarkII
New video thumbnailer, rewritten to try to eliminate a bug in the old one where processing would stall.
New bugs introduce (of course ;)
Collections
Merged - Thanks aaronw!
WebOb => Werkzeug switch
Made some things break. Need help with testing + bugfixes
borked stuffs:

Accessing paths without trailing slashes, e.g. /submit (instead of /submit/)

Still a lot of legacy WebOb responses (such as webob.exc.HTTPFound() HTTPForbidden() left)

API
Delivered to mrn.is, tryggvib will test it and get back with feedback.
Working, still a lot of room for improvements.
Mostly done, usable, still room for improvements. Example applications:

https://github.com/jwandborg/automgtic

https://github.com/jwandborg/omgmg
</pre>

=== September 1st, 2012, 9:00 am Pacific Time (2012-09-01 16:00 UTC) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-09-01.txt IRC log]

* FIXME - can someone type in summary here?

=== August 4th, 2012, 9:00 am Pacific Time (2012-08-04 16:00 UTC) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-08-04.txt IRC log]

* Release schedule
* Plugins and themes! Who's working on one? What problems are you having? -- Please write up issues for problems so they can get fixed!
* Should we namespace plugins? If so, how should we namespace plugins?
** Python 3.3 will have support for namespace plugins. [http://www.python.org/dev/peps/pep-0420/#namespace-packages-today]
** In Python >=2.3, <3.3 it's a hack [http://www.python.org/dev/peps/pep-0402/#the-problem][http://www.python.org/dev/peps/pep-0420/#namespace-packages-today]
** Flask has a workaround[https://github.com/mitsuhiko/flask/blob/master/flask/ext/__init__.py]

=== July 7th, 2012, 9:00 am Pacific Time (2012-07-07 16:00 UTC) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-07-07.txt IRC log]

Announcements:

* Anyone who wants to edit the wiki needs to be in the goblin army group. Ask Will or Chris to get added.
* Plugin infrastructure landed. If you're interested in writing plugins, talk to Will. Some documentation at http://docs.mediagoblin.org/#part-2-plugin-writer-s-guide

Agenda:

* Keyboard shortcuts ([http://issues.mediagoblin.org/ticket/346 #346])
* Ticket triaging?
* Base plugin stuff!
* Theming
* Conference: OSCON
* Chris Webber's new "office hours"

=== June 2nd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-06-02.txt IRC log]

* docs changes
** Will split the docs/ guide into a Site Administrator's Guide and a Plugin Writer's Guide
** Has anyone looked at the Plugin Writer's Guide, yet?
** Will wants to add a "Contributor's Guide" to docs/ which he'd update from the wiki before every release
* Is there a way to improve our unit tests and motivation to write them?
** Simulating a browser by the way of [http://phantomjs.org/ PhantomJS], [http://seleniumhq.org/ Selenium] instead of having code simulating other code against itself might be more natural to write and even more testing the actual application. I have a good feeling about this, please prove me wrong if I'd be. --[[User:Joar|Joar]] 08:53, 28 May 2012 (EDT)
* Administrative panel/tools and user uploads panel
* Git and tickets
* Plugins
** What's the state of things?
** Documentation
** What plugins might we want to build for this upcoming release?
** What things do we currently have that we might want to pluginify?
* State of kuneco/federation mini-update (Chris)

=== May 5th, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-05-05.txt IRC log]

* Post-release reflections
** Woohoo, release!
** How did this release process go?
*** We should talk about that conference.
** What's left to clean up?
*** Mongokit->SQL "style" query conversion?
*** Other cruft code?
* What are our next goals?
** Plugins
** Federation
** Favoriting
*** Take that, Pinterest! ;)
** Galleries
** Theming
*** Using sass would be neat
** Access restrictions
*** User management, or having a "secret url" that is not in the photo index that you can share with friends and generate as needed for any media type
** What about traffic? Some of us will host GMG on limited plans.
** Some kind of coding guidelines? Do we have a philosophy like "Keep it Simple, Stupid"
*** This concerns things like: Should plugins land in core eventually, do we want to support ALL THE MEDIA TYPES, ...
** Podcasting support?
** Things that have been hanging???
** Bugtrackers and milestone?
** More??? We should organize things!
* jancborchardt and his team of UX wizard-students
* Website redesign
* OpenShift?

=== April 7th, 2012, 4:00 pm UTC ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-04-07.txt IRC log]

* Post-SQL stuff
* Pending 0.0.3 release!
* Are there stray patches/branches to be merged?
* Our glorious upcoming plugin future! (Update from Will)

=== March 3rd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-03-03.txt IRC log]

* [[GSOC 2012]]
* State of the SQL transition (preview: it's super close, but we need help!)
* Plugin discussion (Will can't make this, but we should talk about use cases)
* MediaGoblin at upcoming conferences
* PageKite accounts

=== 2012-02 (held on 2012-02-04) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-02-04.txt IRC log]

* Code style guide? See also: http://issues.mediagoblin.org/ticket/197
* Kuneco/federation
* API
* More testing discussion?
* Theming?
* Preliminary plugin discussion
* Status update from the "SQL Team".

Some of the decisions:

* file an issue about proper <audio> support.
* some TODOs recorded

=== 2011-12 (held on 2011-12-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt IRC log]

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))
* [[Feature Ideas]]: What should we do about the wiki page? Keep it and have it as a monthly topic for "what next"? Convert everything to long waiting bugs?
* Possibility of an [[SQL Database Backend]]?
*: 'executive summary' (well, you should read the long docs): "We could move to sql. It's probably replacing one type of pain by another type of pain, but those are somewhat comparable. Leaving the main question: Do we want to occupy our main devs for some long time with this task and loose momentum?"
* Schendje's [http://wiki.mediagoblin.org/Feature_Ideas/Activities activities proposal]
* "Coming up next" blogpost draft by Deb Nicholson
* Jef's requests:
** Ticket #466 "Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be". I'd really like to change this soon to something more suitable. How can we improve the wording here? Some alternatives have been mentioned in the bug report, but which one should we pick? Link: http://bugs.foocorp.net/issues/466
** The concept and naming of "favourites". We'll (hopefully) be able to "favourite" media soon, which I *think* means that 1) it'll work like a "I like this" comment, a quick token of appreciation, 2) it'll be added to your list of favourites so you can save and promote it, and 3) we could maybe use the number of favourites as a ranking. What I'd like to know is: is that the intended purpose? If so, should we name them favo(u)rites or something else? "Like", "love", "save", "appreciate", "heart", "high five" and many more could all be contenders. And the name should be consistent with the action and purpose, of course. So I'd like to clear up how and why we will use favourites and what we should call them.

=== 2011-11 (held on 2011-11-05) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

=== 2011-10 (held on 2011-10-01) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

=== 2011-09 (held on 2011-09-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

=== 2011-08 (held on 2011-08-06) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

Authentication

2013-04-30T23:09:05Z

Rodney757: /* Designing Authentication API */

== Designing Authentication API ==

To make our auth(entication) system more modular, we're likely going to have some sort of interface style API for it. This page is to design it.

== __init__.py Base Class ==

***This is a brainstorm of some of the functions and variables that the base class should include.***

basic_auth = False # Will be used to render to correct forms if using both basic_auth and openid/persona

login_form = # Plugin LoginForm class

registration_form = # Plugin RegistrationForm class

class UserAuthInterface(object):
<nowiki>
deg _raise_not_implemented(self):
# Will raise a warning if some component of this interface isn't implemented by an Auth plugin

def check_login(self, user, password):
return False

def get_user(self, *args):
# Will query database and will return a User() object

def create_user(self, *args):
# Will create a new user and save to the db.
# Will return User() object

def extra_validation(self, register_form, *args):
# Will query the db and add error messages to register_form if any.
# return true if able to create new user

def get_user_metadata(self, user):
# Return a nice object with metadata from auth provider. Used to pre-fill registration forms
</nowiki>

HackingHowto

2013-04-20T22:36:19Z

Rodney757: Making Create a development environment more clear

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at [http://docs.mediagoblin.org/devel/codebase.html codebase chapter] where
we've started documenting how GNU MediaGoblin is built and how to add
new things. If you're planning on contributing in python, you should be aware
of [http://www.python.org/dev/peps/pep-0008/ PEP-8], the official Python style guide,
which we follow.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use an
in-package checkout of virtualenv. This isn't the convenional way to
install virtualenv (normally you don't install virtualenv inside the
package itself) but we've found that it's significantly easier for
newcomers who aren't already familiar with virtualenv. If you *are*
already familiar with virtualenv, feel free to just install
mediagoblin in your own virtualenv setup... the necessary adjustments
should be obvious.

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* SQLAlchemy 0.7.0 or higher - http://www.sqlalchemy.org/
* Python Imaging Library (PIL) - http://www.pythonware.com/products/pil/
* virtualenv - http://www.virtualenv.org/
* Python GStreamer Bindings - http://gstreamer.freedesktop.org/modules/gst-python.html

=== GNU/Linux ===

==== Debian and derivatives ====

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

{{Cmd|sudo apt-get install git-core python python-dev python-lxml python-imaging python-virtualenv python-gst0.10 libjpeg8-dev}}

==== Fedora / RedHat(?) ====

On Fedora:

{{Cmd|yum install python-paste-deploy python-paste-script git-core python python-devel python-lxml python-imaging python-virtualenv gstreamer-python}}

=== Mac OS X ===

==== Mac OS X Lion ====

Download the Newest Python.

Git is already installed.

Python-lxml: http://muffinresearch.co.uk/archives/2009/03/05/install-lxml-on-osx/ with sudo

Python Imaging Library (PIL): http://code.google.com/appengine/docs/python/images/installingPIL.html#mac

Libjpeg & Libpng: http://ethan.tira-thompson.org/Mac_OS_X_Ports.html Combo Installer

==== Mac OS X Snow Leopard ====

# You will probably want to install MacPorts this will give you access to many free software packages in the same manner to apt-get and yum: https://www.macports.org/install.php
# Ensure you install Git and the command line tools: https://help.github.com/articles/set-up-git#platform-mac
# Once both of those are installed type this in your terminal and enter your password when prompted for it {{Cmd|sudo port install python27 py27-lxml py27-sqlalchemy py27-pil py27-virtualenv py27-gst-python py27-pastescript}}

=== Microsoft Windows ===

''Thanks wctype!''

==== Getting requirements ====

* Python 2.7 - [http://www.python.org/download/ Download] 
* git - [https://github.com/msysgit/git/downloads Download] 
* python-lxml - [http://pypi.python.org/pypi/lxml/2.3.5#downloads Tarball] [http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil Binaries] 
* Python Imaging Library (PIL) - [http://www.pythonware.com/products/pil/ Download] 
* virtualenv - [http://pypi.python.org/pypi/virtualenvwrapper-win/1.0.8#downloads Download] 
* OSSBuild project provides reasonably up-to-date binaries of GStreamer - [https://code.google.com/p/ossbuild/downloads/list Download] 
* py-bcrypt - [https://bitbucket.org/alexandrul/py-bcrypt/downloads/ Download] 

----

'''You can help:'''

If you have instructions for other GNU/Linux distributions, Windows, or Mac OS X to set
up requirements, [http://mediagoblin.org/join/ let us know]!

== How to set up and maintain an environment for hacking with virtualenv ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

* Clone the repository: {{Cmd|git clone <nowiki>git://gitorious.org/mediagoblin/mediagoblin.git</nowiki>}}
* Change directories to your new checkout: {{Cmd|cd mediagoblin}}
* Checkout git submodules: {{Cmd|git submodule init}} {{Cmd|git submodule update}}
* Set up the in-package virtualenv:
(virtualenv --system-site-packages . || virtualenv .)
* Run setup.py:
{{Cmd|./bin/python setup.py develop}}
* Init the database:
{{Cmd|./bin/gmg dbupdate}}

That's it!

(If you have troubles in the remaining steps, consider try installing
virtualenv with one of the flags --setuptools, --distribute or possibly --no-site-packages. Additionally, if your system has python3.X as the default, you might need to do virtualenv --python=python2.7 or --python=python2.6)

If you have problems, please [http://mediagoblin.org/join/ let us know]!

== Updating an existing environment ==

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed.

To do that, run:

{{Cmd|./bin/python setup.py develop --upgrade && ./bin/gmg dbupdate}}

'''Updating for code changes'''

{{Cmd|git pull -u}}
{{Cmd|git submodule update}}

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

{{Cmd|./lazyserver.sh}}

This will start up a python server where you can begin playing with
mediagoblin, listening on 127.0.0.1:6543. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

By default, the instance is not sending out confirmation mails. Instead they are redirected to the standard output (the console) of lazyserver.sh.

You can change this behavior setting <code>email_debug_mode</code> to <code>false</code> in mediagoblin.ini

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

{{Cmd|./bin/paster serve paste.ini --reload}}

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

{{Cmd|<nowiki>CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd</nowiki>}}

== Running the test suite ==

Run:

{{Cmd|./runtests.sh}}

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

{{Cmd|./bin/gmg shell}}

== Troubleshooting ==

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

{{Cmd|rm -rf mediagoblin.db kombu.db celery.db user_dev; ./bin/gmg dbupdate}}

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has SQLAlchemy ORM definitions
* <tt>views.py</tt> is where the views go

We're using SQLAlchemy, which is semi-similar to the Django ORM, but
not really because you can get a lot more fine-grained. The
[http://docs.sqlalchemy.org/en/latest/orm/tutorial.html SQLAlchemy ORM tutorial] is a great place to start.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Showing off your work with PageKite ==

If you're doing development with MediaGoblin, it's sometimes helpful to show off your work to gather feedback from other contributors. A number of the MediaGoblin developers use something called [http://pagekite.net PageKite], which is a fellow free software web service which makes temporarily showing off work on your machine easy. There's a [http://pagekite.net/wiki/Howto/UsePageKiteWithMediaGoblin/ tutorial on how to use PageKite and MediaGoblin together] available on the PageKite wiki.

If you are doing a lot of MediaGoblin development, the PageKite people have graciously offered us a good amount of bandwidth at no cost in an effort to help out fellow free software projects. If you've been making significant contributions, PM Chris Webber on freenode (who is paroneayea there) and ask if you can be added to our group plan.

== Bite-sized bugs to start with ==

Now you should visit our latest list of [http://issues.mediagoblin.org/query?status=!closed&keywords=~bitesized bite-sized issues] because squishing bugs is messy fun. If you're interested in other things to work on, or need help getting started on a bug, let us know on [http://mediagoblin.org/join/ the mailing list] or on the [http://mediagoblin.org/join/ IRC channel].