Apache EU Roadshow CFP Closing Soon (23 February)

[Sharan F]

Hello Everyone

This is an initial reminder to let you all know that we are holding an 
Apache EU Roadshow co-located with FOSS Backstage in Berlin on 13^th and 
14^th June 2018. https://s.apache.org/tCHx


The Call for Proposals (CFP) for the Apache EU Roadshow is currently 
open and will close at the end of next week, so if you have been 
delaying making a submission because the closing date seemed a long way 
off, then it's time to start getting your proposals submitted.


So what are we looking for?
We will have 2 Apache Devrooms available during the 2 day Roadshow so 
are looking for projects including incubating ones, to submit 
presentations, panel discussions, BoFs, or workshop proposals. The main 
focus of the Roadshow will be IoT, Cloud, Httpd and Tomcat so if your 
project is involved in or around any of these technologies at Apache 
then we are very interested in hearing from you.


Community and collaboration is important at Apache so if your project is 
interested in organising a project sprint, meetup or hackathon during 
the Roadshow, then please submit it inthe CFP as we do have some space 
available to allocate for these.


If you are wanting to submit a talk on open source community related 
topics such as the Apache Way, governance or legal aspects then please 
submit these to the CFP for FOSS Backstage.


Tickets for the Apache EU Roadshow are included as part of the 
registration for FOSS Backstage, so to attend the Roadshow you will need 
to register for FOSS Backstage. Early Bird tickets are still available 
until the 21^st February 2018.


Please see below for important URLs to remember:

-  To submit a CFP for the Apache EU Roadshow 
:http://apachecon.com/euroadshow18/ 


-  To submit a CFP for FOSS Backstage : 
https://foss-backstage.de/call-papers


-  To register to attend the Apache EU Roadshow and/or FOSS Backstage : 
https://foss-backstage.de/tickets


For further updates and information about the Apache EU Roadshowplease 
check http://apachecon.com/euroadshow18/


Thanks
Sharan Foga, VP Apache Community Development

[jira] [Updated] (SHIRO-621) REST filter bypassing matched path

[Shilpi Das (JIRA)]

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

Shilpi Das updated SHIRO-621:
-
Description: 
The following filter chains are present in configureShiroWeb() function

addFilterChain("/**/first/second/third/**", filterConfig(AUTHC_BASIC), 
filterConfig(REST, "X"));
 addFilterChain("/**/first/**", filterConfig(AUTHC_BASIC), filterConfig(REST, 
"Y"));

When a request is made for an API- example.appspot.com/v1/first/second/third, 
the first filter is bypassed and the access is granted for a user with 
permission Y and not with X.

I am using Shiro 1.4.0-RC2 version and Guice 3.0.

I have also tried using Shiro 1.4.0 with Guice 4.0.

With Shiro 1.4.0 and Guice 4.0:

The {{ShiroWebModule}} class is creating a randomly ordered path to config map 
in {{filterToPathToConfig}}, because it's using a HashMap instead of a 
LinkedHashMap.

The offending line is here:
 
[https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java|https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java#L144]
 #L161

This should be a LinkedHashMap to maintain original user order.

  was:
The following filter chains are present in configureShiroWeb() function

addFilterChain("/**/first/second/third/**", filterConfig(AUTHC_BASIC), 
filterConfig(REST, "X"));
 addFilterChain("/**/first/**", filterConfig(AUTHC_BASIC), filterConfig(REST, 
"Y"));

When a request is made for an API- example.appspot.com/v1/first/second/third, 
the first filter is bypassed and the access is granted for a user with 
permission Y and not with X.

I am using Shiro 1.4.0-RC2 version and Guice 3.0.

I have also tried using Shiro 1.4.0 with Guice 4.0.

With Shiro 1.4.0 and Guice 4.0:

{{The ShiroWebModule class is creating a randomly ordered path to config map in 
filterToPathToConfig, because it's using a HashMap instead of a LinkedHashMap.}}

The offending line is here:
[https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java|https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java#L144]
 #161

This should be a LinkedHashMap to maintain original user order.


> REST filter bypassing matched path
> --
>
> Key: SHIRO-621
> URL: https://issues.apache.org/jira/browse/SHIRO-621
> Project: Shiro
>  Issue Type: Bug
>  Components: Integration: Guice
>Affects Versions: 1.4.0-RC2, 1.4.0
> Environment: Google App Engine
>Reporter: Shilpi Das
>Assignee: Jared Bunting
>Priority: Major
>
> The following filter chains are present in configureShiroWeb() function
> addFilterChain("/**/first/second/third/**", filterConfig(AUTHC_BASIC), 
> filterConfig(REST, "X"));
>  addFilterChain("/**/first/**", filterConfig(AUTHC_BASIC), filterConfig(REST, 
> "Y"));
> When a request is made for an API- example.appspot.com/v1/first/second/third, 
> the first filter is bypassed and the access is granted for a user with 
> permission Y and not with X.
> I am using Shiro 1.4.0-RC2 version and Guice 3.0.
> I have also tried using Shiro 1.4.0 with Guice 4.0.
> With Shiro 1.4.0 and Guice 4.0:
> The {{ShiroWebModule}} class is creating a randomly ordered path to config 
> map in {{filterToPathToConfig}}, because it's using a HashMap instead of a 
> LinkedHashMap.
> The offending line is here:
>  
> [https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java|https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java#L144]
>  #L161
> This should be a LinkedHashMap to maintain original user order.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SHIRO-621) REST filter bypassing matched path

[Shilpi Das (JIRA)]

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

Shilpi Das updated SHIRO-621:
-
  Flags: Important
Description: 
The following filter chains are present in configureShiroWeb() function

addFilterChain("/**/first/second/third/**", filterConfig(AUTHC_BASIC), 
filterConfig(REST, "X"));
 addFilterChain("/**/first/**", filterConfig(AUTHC_BASIC), filterConfig(REST, 
"Y"));

When a request is made for an API- example.appspot.com/v1/first/second/third, 
the first filter is bypassed and the access is granted for a user with 
permission Y and not with X.

I am using Shiro 1.4.0-RC2 version and Guice 3.0.

I have also tried using Shiro 1.4.0 with Guice 4.0.

With Shiro 1.4.0 and Guice 4.0:

{{The ShiroWebModule class is creating a randomly ordered path to config map in 
filterToPathToConfig, because it's using a HashMap instead of a LinkedHashMap.}}

The offending line is here:
[https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java|https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java#L144]
 #161

This should be a LinkedHashMap to maintain original user order.

  was:
The following filter chains are present in configureShiroWeb() function

addFilterChain("/**/first/second/third/**", filterConfig(AUTHC_BASIC), 
filterConfig(REST, "X"));
 addFilterChain("/**/first/**", filterConfig(AUTHC_BASIC), filterConfig(REST, 
"Y"));

When a request is made for an API- example.appspot.com/v1/first/second/third, 
the first filter is bypassed and the access is granted for a user with 
permission Y and not with X.

I am using Shiro 1.4.0-RC2 version and Guice 3.0.

I have also tried using Shiro 1.4.0 with Guice 4.0.


> REST filter bypassing matched path
> --
>
> Key: SHIRO-621
> URL: https://issues.apache.org/jira/browse/SHIRO-621
> Project: Shiro
>  Issue Type: Bug
>  Components: Integration: Guice
>Affects Versions: 1.4.0-RC2, 1.4.0
> Environment: Google App Engine
>Reporter: Shilpi Das
>Assignee: Jared Bunting
>Priority: Major
>
> The following filter chains are present in configureShiroWeb() function
> addFilterChain("/**/first/second/third/**", filterConfig(AUTHC_BASIC), 
> filterConfig(REST, "X"));
>  addFilterChain("/**/first/**", filterConfig(AUTHC_BASIC), filterConfig(REST, 
> "Y"));
> When a request is made for an API- example.appspot.com/v1/first/second/third, 
> the first filter is bypassed and the access is granted for a user with 
> permission Y and not with X.
> I am using Shiro 1.4.0-RC2 version and Guice 3.0.
> I have also tried using Shiro 1.4.0 with Guice 4.0.
> With Shiro 1.4.0 and Guice 4.0:
> {{The ShiroWebModule class is creating a randomly ordered path to config map 
> in filterToPathToConfig, because it's using a HashMap instead of a 
> LinkedHashMap.}}
> The offending line is here:
> [https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java|https://github.com/apache/shiro/blob/master/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java#L144]
>  #161
> This should be a LinkedHashMap to maintain original user order.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)