Meeting this week
by Tom Callaway
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
15 years, 2 months
Moksha App List
by John (J5) Palmieri
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.
15 years, 2 months
Added csrf protection and script culling
by John (J5) Palmieri
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.
15 years, 2 months
Moksha Demo Deployment
by Luke Macken
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
15 years, 2 months
ToscaWidget WidgetBrowser integration
by Luke Macken
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/
15 years, 2 months
Status Meeting
by Tom Callaway
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
15 years, 2 months
On vacation on friday the 6th, back to work Tuesday the 10th
by John (J5) Palmieri
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.
15 years, 2 months
Moksha now has placeholders for containers
by John (J5) Palmieri
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.
15 years, 2 months
