SIDEBAR
»
S
I
D
E
B
A
R
«
Atlassian dropping IE 6 support
Feb 8th, 2010 by P.G.Taboada

I found this one here in the atlassian forums, unfortunately the link posted there is broken.

Hi guys,

We are announcing our end of life of Atlassian support for Internet Explorer 6 on JIRA.

This will be effective from the launch date of JIRA 4.2 (target Q3, 2010). This means that JIRA 4.1 will be the last version of JIRA to support IE6. (From JIRA 4.0 to JIRA 4.1, all of the main functionality will work in IE 6; however, some of the visual effects will be missing).

The End of Support Announcements for JIRA specifies end of support for browsers, appserver and JDK. We should add Atlassian products to the IE death march.

Jira Plugin & Log4J
Feb 25th, 2009 by P.G.Taboada

I came across this problem lately when I was working on a Jira plugin. A Jira plugin does not rely on a OSGi container or some similar plugin framework. The plugin consists mainly of a jar file that gets deployed with (I mean inside…) the Jira Java EE web application.

Logging is an issue in such an environment: the surrounding application configures the logging API – there is no way to provide log4j configuration fragments.

Read the rest of this entry »

Security Anforderungen 2.0: Gruppen, Rollen, Flexibilität
Apr 28th, 2008 by P.G.Taboada

Was habe ich mich gefreut, als Jira das Sicherheitskonzept um Rollen (Projekt-Rollen) erweitert hat. Statt Rechtekonfigurationen an Benutzergruppen zu binden, hat man jetzt die Möglichkeit Rechte an bestimmte Rollen zu binden. Für jedes Projekt folgt dann die Benutzer/ Rolle Zuweisung: dadurch ergibt sich letztlich, welche Rechte ein Benutzer für ein bestimmtes Projekt haben wird.

Gerade in kleine, agil arbeitende Teams ist das wesentlich effizienter: in einem Projekt ist man der Projektleiter, bei einem anderem lediglich ein Entwickler. So flexibel wie Entwickler heute die Rollen wechseln müssen, so flexibel konfigurierbar muss heute auch unternehmenskritische Software sein. In der Vergangenheit musste man in Jira für jede mögliche Kombination der Rollen in einem Projekt entsprechende Benutzergruppen einführen. Benutzergruppen sind aber statisch/ global und nehmen keine Rücksicht auf besondere Projektgegebenheiten. Am Ende bekommt jedes Projekt eigene Benutzergruppen.

Die Einführung von Projektrollen und Sicherheitskonfigurationen für Projektrollen im Allgemeinen reduziert die Konfiguration drastisch. Danke Atlassian!

Ein Rollenmodell ist nicht mit den heute üblichen deklarativen Mitteln konfigurierbar. Wir scheitern an der instanzbasierten Sicherheit. Je nach Projekt hat der Benutzer andere Rollen. Um so wichtiger ist es, ein Security Framework zu wählen, mit dem man die nötige Flexibilität und die Möglichkeit bekommt, eigene Anforderungen umzusetzen.

Auch wenn JAAS ein beeindruckendes Werk ist, mangelt es meiner Meinung nach an Flexibilität. Anpassungen sind sehr schnell nicht mehr portabel, eine Bindung zu der Laufzeitumgebung und oder Infrastruktur ist das Ergebenis. Spring Security (formerly known as Acegi) ist hingegen sehr flexibel. Security wird dadurch nicht trivial, aber besondere Anforderungen und entsprechende Lösungsansätze scheitern nicht mehr an dem Framework.

Schade dass in der Spring Security Dokumentation zu diesem Thema nichts zu finden ist. Eine Interessante Ausarbeitung zum Thema Gruppen und Rollen auf Konzeptebene ist hier zu finden.

SIDEBAR
»
S
I
D
E
B
A
R
«
»  Substance:WordPress   »  Style:Ahren Ahimsa
Bitnami