Dave Dombrosky (JIRA | 2 Dec 17:01 2010
Picon

[jira] Created: (SHIRO-220) Fix links to Issue Tracker

Fix links to Issue Tracker
--------------------------

                 Key: SHIRO-220
                 URL: https://issues.apache.org/jira/browse/SHIRO-220
             Project: Shiro
          Issue Type: Task
          Components: Documentation
            Reporter: Dave Dombrosky
            Priority: Minor

The links for the Shiro Issue Tracker are not working on the
http://shiro.apache.org/how-to-contribute.html page.  They are currently pointing to:

https://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=SHIRO&title=Issue%20Tracker&linkCreation=true&fromPageId=5964195

But they should instead point to:

https://issues.apache.org/jira/browse/SHIRO

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Kalle Korhonen (JIRA | 2 Dec 17:53 2010
Picon

[jira] Assigned: (SHIRO-220) Fix links to Issue Tracker


     [
https://issues.apache.org/jira/browse/SHIRO-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kalle Korhonen reassigned SHIRO-220:
------------------------------------

    Assignee: Kalle Korhonen

> Fix links to Issue Tracker
> --------------------------
>
>                 Key: SHIRO-220
>                 URL: https://issues.apache.org/jira/browse/SHIRO-220
>             Project: Shiro
>          Issue Type: Task
>          Components: Documentation
>            Reporter: Dave Dombrosky
>            Assignee: Kalle Korhonen
>            Priority: Minor
>
> The links for the Shiro Issue Tracker are not working on the
http://shiro.apache.org/how-to-contribute.html page.  They are currently pointing to:
> https://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=SHIRO&title=Issue%20Tracker&linkCreation=true&fromPageId=5964195
> But they should instead point to:
> https://issues.apache.org/jira/browse/SHIRO

--

-- 
This message is automatically generated by JIRA.
-
(Continue reading)

Kalle Korhonen (JIRA | 2 Dec 18:03 2010
Picon

[jira] Resolved: (SHIRO-220) Fix links to Issue Tracker


     [
https://issues.apache.org/jira/browse/SHIRO-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kalle Korhonen resolved SHIRO-220.
----------------------------------

    Resolution: Fixed

Thanks for reporting!

> Fix links to Issue Tracker
> --------------------------
>
>                 Key: SHIRO-220
>                 URL: https://issues.apache.org/jira/browse/SHIRO-220
>             Project: Shiro
>          Issue Type: Task
>          Components: Documentation
>            Reporter: Dave Dombrosky
>            Assignee: Kalle Korhonen
>            Priority: Minor
>
> The links for the Shiro Issue Tracker are not working on the
http://shiro.apache.org/how-to-contribute.html page.  They are currently pointing to:
> https://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=SHIRO&title=Issue%20Tracker&linkCreation=true&fromPageId=5964195
> But they should instead point to:
> https://issues.apache.org/jira/browse/SHIRO

--

-- 
(Continue reading)

Kalle Korhonen | 6 Dec 18:29 2010
Picon

<at> RequiresAssociation

In my projects, I repeatedly find a need to express a permission rule
for allowing the currently executing subject to access or modify an
instance of a persistent type when the subject is in some way
associated to the said instance. For example, a user should only be
allowed update his own profile. I had implemented this
association/instance based security concept for Trails framework (see
http://trails.codehaus.org/Security+module) earlier and now, I'd like
to be able to do the same for tapestry-security
(http://tynamo.org/tapestry-security+guide). With the more flexible
 <at> RequiresPermissions you could theoretically implement much more
complex association-based permission rules but in practice I've found
that the security rules based on primary type's association to the
executing subject solves at least 80% of the use cases, which could be
expressed with a more specialized and simpler-to-use
 <at> RequiresAssociation annotation.

I could simply implement  <at> RequiresAssociation for tapestry-security
only, but I would assume that it would be equally useful for Wicket
and Grails and especially for any framework using Hibernate/JPA
persistence because add-on security rules are easy to express with the
criteria API.  <at> RequiresAssociation could live in Shiro and have bare
bones support for it similar to  <at> RequiresPermissions. Shiro-based
security libraries could then make more complete integrations with
their favorite web framework, utilizing the same annotation. Would
other Shiro devs and community find this useful and reasonable and
worth implementing in the Shiro core itself?

Kalle

(Continue reading)

Les Hazlewood | 6 Dec 20:07 2010
Picon

Next release

Do you guys wanna try to get out at least a point release to clear out
as many issues as we can before the holidays?  I think it'd be a good
idea.  Any ideas?

Regards,

Les

Les Hazlewood | 6 Dec 20:11 2010
Picon

Re: <at> RequiresAssociation

Hi Kalle,

Do you envision this as existing in the Shiro API namespace, but
perhaps not interpreted by anything in Shiro at the moment?  I.e.
adding it to Shiro so it can be 'common' among integrating frameworks?

I'm not entirely sure how Shiro core could support such a thing since
it requires knowledge of a data model (i.e. I don't know what would be
the 'bare bones support').  How would it be used and/or supported by
other frameworks?

Anything we can do to support this use case would be great - I'm just
trying to see how it would be used in practice so we can make it
useful in a generic way.

Thanks,

Les

On Mon, Dec 6, 2010 at 9:29 AM, Kalle Korhonen
<kalle.o.korhonen@...> wrote:
> In my projects, I repeatedly find a need to express a permission rule
> for allowing the currently executing subject to access or modify an
> instance of a persistent type when the subject is in some way
> associated to the said instance. For example, a user should only be
> allowed update his own profile. I had implemented this
> association/instance based security concept for Trails framework (see
> http://trails.codehaus.org/Security+module) earlier and now, I'd like
> to be able to do the same for tapestry-security
> (http://tynamo.org/tapestry-security+guide). With the more flexible
(Continue reading)

Kalle Korhonen | 6 Dec 20:14 2010
Picon

Re: Next release

I'm pretty busy just before the holidays. I don't see a burning need
for a point release but will certainly support it if you think it's
worth the effort. Did you have some specific issues in mind that you'd
like to get into a release?

Kalle

On Mon, Dec 6, 2010 at 11:07 AM, Les Hazlewood <lhazlewood@...> wrote:
> Do you guys wanna try to get out at least a point release to clear out
> as many issues as we can before the holidays?  I think it'd be a good
> idea.  Any ideas?
>
> Regards,
>
> Les
>

Kalle Korhonen | 6 Dec 20:26 2010
Picon

Re: <at> RequiresAssociation

On Mon, Dec 6, 2010 at 11:11 AM, Les Hazlewood <lhazlewood@...> wrote:
> Do you envision this as existing in the Shiro API namespace, but
> perhaps not interpreted by anything in Shiro at the moment?  I.e.
> adding it to Shiro so it can be 'common' among integrating frameworks?
> I'm not entirely sure how Shiro core could support such a thing since
> it requires knowledge of a data model (i.e. I don't know what would be
> the 'bare bones support').  How would it be used and/or supported by
> other frameworks?
> Anything we can do to support this use case would be great - I'm just
> trying to see how it would be used in practice so we can make it
> useful in a generic way.

Yes, I'd envision the  <at> RequiresAssociation go into shiro core,
possibly accompanied with an enum for denoting the targeted
CRUD-operation. Perhaps a getAssociation() helper for aspectj-module
and whatever helpers you could possibly use together with Spring (say
you put the annotation on a Spring bean and the association maps to a
referenced bean by that name), sort of as a reference implementation.
Not just like, but similar to how  <at> RequiresPermission is currently
handled.

Kalle

> On Mon, Dec 6, 2010 at 9:29 AM, Kalle Korhonen
> <kalle.o.korhonen@...> wrote:
>> In my projects, I repeatedly find a need to express a permission rule
>> for allowing the currently executing subject to access or modify an
>> instance of a persistent type when the subject is in some way
>> associated to the said instance. For example, a user should only be
>> allowed update his own profile. I had implemented this
(Continue reading)

Les Hazlewood (JIRA | 9 Dec 19:28 2010
Picon

[jira] Resolved: (SHIRO-197) Ini and Ini.Section should retain key-value definition order


     [
https://issues.apache.org/jira/browse/SHIRO-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Les Hazlewood resolved SHIRO-197.
---------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 1.0.1)
                   1.1.0

This was resolved in Shiro 1.1

> Ini and Ini.Section should retain key-value definition order
> ------------------------------------------------------------
>
>                 Key: SHIRO-197
>                 URL: https://issues.apache.org/jira/browse/SHIRO-197
>             Project: Shiro
>          Issue Type: Bug
>          Components: Configuration
>    Affects Versions: 1.0.0
>            Reporter: Les Hazlewood
>            Assignee: Les Hazlewood
>            Priority: Critical
>             Fix For: 1.1.0
>
>         Attachments: SHIRO-197.patch
>
>
(Continue reading)

Les Hazlewood (JIRA | 9 Dec 19:32 2010
Picon

[jira] Resolved: (SHIRO-184) ShiroFilterFactoryBean 'filterChainDefinitions' property does not retain URL path matching order


     [
https://issues.apache.org/jira/browse/SHIRO-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Les Hazlewood resolved SHIRO-184.
---------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 1.0.1)
                   1.1.0

This was resolved in Shiro 1.1 as a result of resolving SHIRO-197

> ShiroFilterFactoryBean 'filterChainDefinitions' property does not retain URL path matching order
> ------------------------------------------------------------------------------------------------
>
>                 Key: SHIRO-184
>                 URL: https://issues.apache.org/jira/browse/SHIRO-184
>             Project: Shiro
>          Issue Type: Bug
>          Components: Integration: Spring
>    Affects Versions: 1.0.0
>            Reporter: Les Hazlewood
>             Fix For: 1.1.0
>
>         Attachments: shiro-jsecurity.patch
>
>
> Workaround until the next point release: use the 'filterChainDefinitionMap' property instead - it does
retain correct path matching order.
(Continue reading)


Gmane