moksha February 2009

moksha@lists.fedorahosted.org

4 participants
11 discussions

Meeting this week
by Tom Callaway 25 Feb '09

25 Feb '09

Since I was out of the office on Monday, our weekly status meeting is going to happen at 10 AM Eastern (1500 UTC) tomorrow (Thursday, 02/26). The meetings will be broadcast over Fedora Talk. If you are a Fedora Talk user with a soft/voip phone, you can join the conference via 2001@xxxxxxxxxxxxxxxxx or infrastructure@xxxxxxxxxxxxxxxxxx If you wish to dial in via a normal telephone, choose one of these local numbers: * 919-424-0063 - Raleigh, NC * 312-577-0052 - Chicago, IL * 978-303-8021 - Westford, MA * 650-930-9514 - Sunnyvale, CA * 442030518327 - UK The conference call extension is 2001. ~spot

1 0

Moksha App List
by John (J5) Palmieri 24 Feb '09

24 Feb '09

Here is a exhaustive logical list of application that need to be built. Note that a lot of apps are just cobbling together other apps in the right order and some apps (like the ones in profile and people) are basically the same applications with different filters (for instance the name of the person logged in or the name of the person being looked at). I'm going to go through and distil this list down to a generic list of apps that need to be built. Fedora Community App Breakdown w - denotes a Widget which is synchronously loaded into it's parent during the initial request a - denotes an App which is asynchronously loaded in a seperate AJAX request s - denotes static element inside the parent template ep - denotes extension point • Overview (a) • Fedora Banner (s) - static for now but we could make it a dynamic widget • Builds Table (a) - latest rawhide • Updates Table (a) - latest stable and testing • Feed (w) - Planet Fedora • Login (w) • Alerts (a) • Quick Links (w) • My Packages (w) - compact • My Profile (a) • Info (a) • User Info Box (w) - also need edit user info • Membership Info (a) - miniview • Feed (w) - your latest blog posts • My Packages (w) - canvas and compact • Alerts (a) • Quick Links (w) • Memberships (a) • User Info Box (w) - compact • Membership Info (a) - larger view (approved and unapproved) • Your Packages (w) - compact view • Alerts (a) • Quick Links (w) • Package Maintenance (a) • User Info Box (w) - compact • Packages You Own (a) - full table • My Packages (w) - canvas and compact • Alerts (a) • Quick Links (w) • Package Maintenance (a) • Packages • No package selected • Package Table (a) - list packages • Filter Box (w) - package filters • Package selected • Overview(a) • Description (s) • Latest Rawhide Build (ep) • Owner (s) • Recent Events (a) • Updates Table(a) - Active release overview • Package resource links(s) • Changelog list(a) • Downloads (a) • Downloads table(a) • Maintainers (a) • ACL Table(a) - Users • ACL Table(a) - Groups • Owners(a) • ACL Table(a) - Owners • Watchers(a) • ACL Table(a) - Watchers • Builds • Builds Table(a) • Changelog • Changelog Table(a) • Updates • Updates Table(a) • Bugs • Bugs Table(a) • Builds (a) • Overview (a) • Builds Table (a) - in progress • Builds Table (a) - failed builds • Builds Table (a) - Successful builds • In-Progress, Failed and Successful Builds (a) • Builds Table (a) - whatever type is selected • Quick Links (w) - views for builds • Updates (a) • Overview (a) • Updates Notice Board (a) • Updates Table (a) - Unpushed • Updates Table (a) - Testing • Updates Table (a) - Stable • Unpushed, Testing, Stable (a) • Updates Table Table (a) - whatever type is selected • Quick Links (w) - views for updates • People • Person selected • Info (a) • User Info Box (a) • Membership Info (a) - miniview • Feed (a) - user's blog posts • Users Packages (w) - compact • Alerts (a) - user's alerts • Quick Links (w) • Memberships (a) • User Info Box (a) - compact • Group Memberships (a) • Package Maintenance (a) • Packages Owned (a) • User Info Box (a) - compact • Package Table (a) - filtered on user and owned • Packages Maintained (a) • User Info Box (a) - compact • Package Table (a) - filtered on user and maintained • Builds Overview (a) • User Info Box (a) - compact • Builds Table (a) - in progress filtered on user • Builds Table (a) - failed builds filtered on user • Builds Table (a) - Successful builds filtered on user • In progress Builds (a) • User Info Box (a) - compact • Builds Table (a) - in progress filtered on user • Failed Builds • User Info Box (a) - compact • Builds Table (a) - failed builds filtered on user • Successful Build • User Info Box (a) - compact • Builds Table (a) - Successful builds filtered on user • Updates Overview (a) • User Info Box (a) - compact • Updates Notice Board (a) - filtered on user • Updates Table (a) - Unpushed filtered on user • Updates Table (a) - Testing filtered on user • Updates Table (a) - Stable filtered on user • Unpushed Updates (a) • User Info Box (a) - compact • Updates Table Table (a) - Unpushed filtered on user • Testing Updates (a) • User Info Box (a) - compact • Updates Table Table (a) - Testing filtered on user • Stable (a) • User Info Box (a) - compact • Updates Table Table (a) - Stable filtered on user • No person selected • People Table (a) • Search • Search Bar (w) • Search Results (a) - Packages • Search Results (a) - People -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 1

Added csrf protection and script culling
by John (J5) Palmieri 19 Feb '09

19 Feb '09

So csrf protection is 90% except for the link rewriting and unauthenticated access. The nice this is this will work for all moksha apps, not just TG with one caveat, posts will return the _csrf_token if the app get the post variables directly from wsgi.input. If they get it from the paste cache then the key is stripped so apps don't have to accept **kwds in their controllers or use an application platform specific hook for stripping unknown keywords. In order to get this working for your app you need to add the csrf repoze.who metadata plugin as the LAST plugin and make sure that your authentication plugin sets environ['CSRF_AUTH_SESSION_ID'] to the session id in the IAuthenticatorPlugin. This is because right after Auth we do redirects. CSRF protection trys to protect against unauthorized redirects and links, by setting CSRF_AUTH_SESSION_ID we can tokenize the just added session ID and rewrite the redirect to pass this arg. The plugin is in fedoracommunity/connectors/csrfwhoplugin.py for now but should move to Moksha. There is also a MokshaGlobals widget that injects javascript into the template so javascript can access the csrf token (moksha_csrf_token). In order for this to work templates must include moksha's template/index.mak template or render the resource injector widget which is in the tmpl_context. The TabbedContainer and DashboardContainer fully support URL rewriting for their child apps. How does this all work? When you are logged in repoze.who runs the auth plugin. As mentioned above the auth plugin needs to set environ['CSRF_AUTH_SESSION_ID']. For every request repoze.who runs a list of metadata plugins which fill in the identity information (and in fedora-community's case the repoze.what authorization credentials). When we hit the csrf plugin it will generate the token and set it in identity['_csrf_token']. If CSRF_AUTH_SESSION_ID is set it will overwrite identity['_csrf_token'] with the sha1 of the of the new authenticated session id (remember if this is a new authentication we still have not hit the browser so we have the old session_id). If this is not an authentication request we check the identity csrf token against the _csrf_token parameter sent by the request. If they match, do nothing. If they don't, delete the repoze.what credentials but not the identity. This is why the plugin has to run last. We keep the user logged in (authenticated) but not authorized to do anything so we can offer password-less re-auth. repoze.what predicates will always think the user is anonymous but if an app checks identity directly they will not be protected. In the browser the moksha_csrf_token variable is set as a global and the containers use the moksha.csrf_rewrite_url method to inject the token into the app they are loading. TODO * Write a predicate that checks if the user is authenticated but not authorized so we can notify the user they need to reauth by pressing the login button * transparent url rewriting on link clicks * tg.url monkey patch * determine if a url is external and should not be rewritten. * metadata plugins only run for authenticated users and that is where we strip the token from the params. In order to hack around this we need to add an identity plugin which strips the token and places it in the environ since identity is run every request. This is a hack because we aren't actually identifying a user. Script Culling We now keep a global hash of the scripts that load and strip scripts that have already been loaded. This hashes the whole path so if you load jQuery from two different places it can't distinguish between the two. I may give an option to hash the filename only but this will still break if the file is versioned or compressed with a different name. Have fun. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Menu API
by Luke Macken 16 Feb '09

16 Feb '09

Hey all, I recently added an experimental dynamic menu API to moksha. You can see a demo here: http://65.49.60.166/ (supports right-click menus as well). The API is currently very basic https://fedorahosted.org/moksha/browser/moksha/api/menus/widgets.py And you can see it being used here: https://fedorahosted.org/moksha/browser/moksha/api/menus/default.py I'll be polishing up the API, and writing some documentation for it soon. Cheers, luke

1 0

Moksha Demo Deployment
by Luke Macken 16 Feb '09

16 Feb '09

Hey all, I deployed a Moksha demo on my Linode a couple of weeks ago:: http://65.49.60.166/ It's currently deployed using Apache+mod_wsgi, which seems to scale pretty well. In the process of deploying, I added an 'archive_tw_resources' setup.py command, which will extract all widget resources to a local 'toscawidgets' directory, allowing us to have apache serve them up. I committed the mod_wsgi config and application in git. I've also been working on integrating with Nginx + memcached, which is *MUCH FASTER* than the mod_wsgi deployment. I committed the Moksha nginx configuration, along with some helper decorators today. I'll be throwing together some formal documentation for this deployment in the very near future. luke

1 0

ToscaWidget WidgetBrowser integration
by Luke Macken 16 Feb '09

16 Feb '09

Hey all, I recently integrated the ToscaWidgets WidgetBrowser[0] into Moksha, using the new WSGI plugin infrastructure. I'm currently mounting the WidgetBrowser on /docs, which automatically integrates our Sphinx documentation into Moksha itself. This will compile the docs upon startup, and allows us to embed live widget demos into our documentation. You can see an example live widget demo here:: http://65.49.60.166/docs/main/LiveWidget.html Adding a widget demo is as simple as this:: .. widgetbrowser:: moksha.widgets.demos.LiveFeedDemo :tabs: demo, source, template, parameters :size: large Cheers, luke [0]: http://toscawidgets.org/documentation/WidgetBrowser/

1 0

Mounting WSGI applications
by Luke Macken 16 Feb '09

16 Feb '09

Hey all, I recently added support for mounting existing WSGI applications, just as you would mount a TG Controller within Moksha. All you have to do is point to your WSGI app in the ``moksha.wsgiapp`` entry-point like so, and it'll be accessible via the same apps interface:: [moksha.wsgiapp] mywsgiapp = mywsgiapp.wsgiapp:MyWSGIApplication Documentation can be found here: http://65.49.60.166/docs/main/MokshaApplications.html#mounting-an-existing-… luke

1 0

Status Meeting
by Tom Callaway 10 Feb '09

10 Feb '09

Due to me being in route from Europe on Monday, our normal meeting did not happen. I would like to reschedule for tomorrow (Wednesday, Feb 11, 2009) at our usual time (1500 UTC). J5, Mo, Luke, speak now, or I'll assume that you'll be there in person. :) ~spot

3 2

On vacation on friday the 6th, back to work Tuesday the 10th
by John (J5) Palmieri 04 Feb '09

04 Feb '09

Just to let moksha and fedora community people know, I will be taking a four day (2 work day) vacation starting this Friday. I will be back hacking Tuesday morning and will only be reachable by phone in between. If someone needs me get in touch with Luke or Spot and they can relay the message. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Moksha now has placeholders for containers
by John (J5) Palmieri 04 Feb '09

04 Feb '09

What are placeholders? Simply put you can configure an application to load in a container and if it isn't registered yet a placeholder is displayed. Why is this useful? It acts like a live checklist of what needs to be done. Setup your site with all the navigation and applications you are going to use and then write each application and register its entry_point. Every time you finish an application you will nearly instantly see it running on your site. When there are no more placeholders left you know you have completed your site. How do I use them? If you use the containers that reside in moksha.api.widgets.containers you get it for free. Note this only works for the MokshaApp configuration wrappers (and soon the MokshaWidget wrapper). If the container can't find the app you specified in the config it will simply replace it with a placeholder which displays the entry point that could not be found. Implement that entry point, register it and restart your server and the placeholder will disappear leaving you with your running app. I've been laying out the fedoracommunity skeleton so you can check it out there. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

moksha February 2009