moksha April 2009

moksha@lists.fedorahosted.org

6 participants
16 discussions

publictest16 update (Updates working, alerts fixed, error logs fixed, tab widget fixes, new mockup for packages 99% done )
by John (J5) Palmieri 22 Apr '09

22 Apr '09

* Updates works again (active releases) - fixed some of my code which checks for status so it works when status is not set (e.g. show me all updates) * Alerts fixed - recent changes which add a username parameter broke alerts when username is not set. Give it a default of None. * error logs fixed - a change to how we register connector methods meant the method was getting the wrong params, fix the method signature to get the right params * tab widget fixes - make sure the tab div id is unique from the whole widget id so we only select li tags inside the tabs div when converting the li's to tabs. Also make sure to use our list of tab li's when clearing the selected tab so that you don't get double selections. Formerly the code was using siblings() to clear the selections but sidebar navigation is split into one ul per category so siblings() would only clear the selection of li's in the same category. * Mo's new mockup is implemented except for the package details and package maintenance tools tabs which are hard to implement because they don't actually change the page like normal tabs do and are two way (i.e. the sidebar nav must tell it's parent nav to switch tabs when a selection in a different category is clicked and vise versa). I'm not sure if it it worth the trouble. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Banners for the Fedora Community Tour
by Máirín Duffy 17 Apr '09

17 Apr '09

Been working on ideas for a tour launched from the front page... http://duffy.fedorapeople.org/temp/misc/fc-banners/banner-pro.png http://duffy.fedorapeople.org/temp/misc/fc-banners/paintain.png ~m

1 0

Code review request: CSRF prevention
by Luke Macken 16 Apr '09

16 Apr '09

Hi everyone, Last night I did a lot of hacking on Moksha's CSRF middleware along with our repoze.who CSRF metadata provider. It seems to be working fine, but I would like a couple more people to review it before we can deem it as safe. Here is the code:: https://fedorahosted.org/moksha/browser/moksha/middleware/csrf.py Test cases:: https://fedorahosted.org/moksha/browser/moksha/tests/functional/test_csrf.py Output of test cases:: CSRFProtectionMiddleware(/) Clearing identity CSRFProtectionMiddleware(/moksha_admin/) Clearing identity CSRFProtectionMiddleware(/login) Clearing identity CSRFMetadataProvider.add_metadata(/login_handler) session cookie= None Invalid session cookie, not setting CSRF token! CSRFMetadataProvider.add_metadata(/post_login) session cookie= 'cabcb2bf43f60590aafbebbd8ff3430549bfba40manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/post_login) Auth state... rewriting headers response.location = http://localhost/moksha_admin/?_csrf_token=4290e910c55274607ed54bf6a8df5513… CSRFMetadataProvider.add_metadata(/moksha_admin/) session cookie= 'cabcb2bf43f60590aafbebbd8ff3430549bfba40manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/moksha_admin/) csrf_token_id in GET User supplied CSRF token match environ! CSRFMetadataProvider.add_metadata(/moksha_admin/) session cookie= 'cabcb2bf43f60590aafbebbd8ff3430549bfba40manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/moksha_admin/) csrf_token_id in POST User supplied CSRF token match environ! CSRFMetadataProvider.add_metadata(/moksha_admin/) session cookie= 'cabcb2bf43f60590aafbebbd8ff3430549bfba40manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/moksha_admin/) Clearing identity Deleting repoze.who.identity from environ Deleting repoze.what.credentials from environ Invalid CSRF token. User supplied (None) doesn't match what's in our environ (4290e910c55274607ed54bf6a8df551387beeabb) Logging the user out CSRFProtectionMiddleware(/moksha_admin/) csrf_token_id in POST Clearing identity CSRFProtectionMiddleware(/) Clearing identity CSRFProtectionMiddleware(/moksha_admin/) Clearing identity CSRFProtectionMiddleware(/login) Clearing identity CSRFMetadataProvider.add_metadata(/login_handler) session cookie= '' Invalid session cookie, not setting CSRF token! CSRFMetadataProvider.add_metadata(/post_login) session cookie= '091657d7699155ff19603ea6a6440e7a49bfba41manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/post_login) Auth state... rewriting headers response.location = http://localhost/moksha_admin/?_csrf_token=28aca41ba0510496c96b2523e9eece52… CSRFMetadataProvider.add_metadata(/moksha_admin/) session cookie= '091657d7699155ff19603ea6a6440e7a49bfba41manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/moksha_admin/) csrf_token_id in POST Clearing identity Deleting repoze.who.identity from environ Deleting repoze.what.credentials from environ Invalid CSRF token. User supplied (4290e910c55274607ed54bf6a8df551387beeabb ) doesn't match what's in our environ (28aca41ba0510496c96b2523e9eece524b4f369e) Logging the user out . ---------------------------------------------------------------------- Ran 1 test in 2.140s OK

2 1

found fix to crazy css problem!!!11
by Máirín Duffy 08 Apr '09

08 Apr '09

I am so excited I just had to send an email!!! I found a solution to the weird CSS issue we've been having with the profile pages user summary rounded box / block. I ran into it again when trying to do the css for the bug dashboard. All is well if the parent div's overflow attribute is set to auto. For whatever reason (and I think this may be a browser bug), the overflow of the parent element is being rendered as if it was set to "visible" (which is not the default value, "auto" should be.) When overflow is set to visible, the way it is supposed to behave is to calculate how tall/wide the content is, and allow it to spill out of its parent block (as opposed to limiting it to the borders of the parent block and adding horiz and/or vert scrollbars, or as opposed to clipping it.) The "auto" property tells the browser 'just figure it out'. For some reason, the browser: (1) thinks that overflow is set to visible for wahtever weird reason (2) thinks the area that needs to spill out of the parent block is way bigger than it actually is. Anyhow, setting overflow: auto seems to fix it for both the profile pages and for the package > bugs page, so expect to see those fixes soon. ~m (ps I am SO EXCITED to find a clean solution to this!)

2 1

Fedora Community Beta Logo
by Máirín Duffy 08 Apr '09

08 Apr '09

Hi, I did three quick mockups of potential beta logos for the Fedora Community app. Any thoughts on which one you'd prefer? Here's the links to the mockups and my take on each: 1. Beta Logo 1: http://duffy.fedorapeople.org/webdesign/My%20Fedora/beta-logos/beta1.png Nobody is going to miss this one. It stands out with a warm color so it's going to be very, very clear the site is in beta. 2. Beta Logo 2: http://duffy.fedorapeople.org/webdesign/My%20Fedora/beta-logos/beta2.png This one is very subtle. The 'beta' might be missed - it fades into the background more and calls less attention to itself. 3. Beta Logo 3 http://duffy.fedorapeople.org/webdesign/My%20Fedora/beta-logos/beta3.png This one is very noticeable like option 1, but it's blingy and shiny while 1 has a more pixel-y style. Any feedback appreciated! Thanks, ~m

4 6

Updates tables - change suggestions (resend)
by Máirín Duffy 03 Apr '09

03 Apr '09

Hi! Today in the status meeting for Fedora Community we talked about the alignment of different version numbers and release names in the updates applications, eg. as shown in this mock: http://fedoraproject.org/w/uploads/1/1a/Myfedora_otherpersonprofile_updates… After looking through the w3c spec on tables, it doesn't appear that there is a good clean way to represent the data as mocked up. So I would like to propose that we add an additional column, "Version", just for the updates tables (it wouldn't affect the other tables) to display the version numbers in a way that aligns them with the other data relevant only to that version number. Doing this cleanly in the HTML means we'll have accessible tables. Here is how the HTML would look with this proposed change: (I'll use ekiga from the mockup as an example): <table> <thead> <tr> <th>Package</th> <th>Version</th> <th>Date Pushed to Stable</th> <th>Release(s)</th> </tr> </thead> <tbody> <tr class="tall-row"> <td class="tall-row-label" rowspan="2">Ekiga</td> <td>2.2.4-7.fc10</td> <td>9 Jan 2009</td> <td>Fedora 10</td> </tr> <tr class="sub-row last-sub-row"> <td>2.2.4-7.fc9</td> <td>9 Jan 2009</td> <td>Fedora 9</td> </tr> </tbody> </table> This is what the HTML will look like given the CSS provided below: http://duffy.fedorapeople.org/temp/misc/Screenshot-1.png What do you think? ~m .header-list table tr.tall-row td, .header-list table tr.sub-row td { border-bottom: none !important; } .header-list table tr.tall-row td.tall-row-label, .header-list table tr.last-sub-row td { border-bottom: 1px solid #c8c8c8 !important; }

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

moksha April 2009