[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts

2017-03-27 Thread Jeffrey E Rodriguez (JIRA)

[ 
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942881#comment-15942881
 ] 

Jeffrey E  Rodriguez commented on KNOX-751:
---

Was revisiting this again.

An example can illustrate what is that we need. 

HDFS UI now has links to DataNode UI servers, each DataNode server has its own 
hostname. 
For Knox to map to rewrite to multiple host of the same type (as above the 
DataNode UI, we have to options.


 DATANODE
 http://foo:50075




1. Create different topology files. datanode1.xml  datanode2.xml  datanode3.xml 
datanodeN.xml
Each one of the new topologies can map a unique datanode host per topology.
The only issue here is that the URL path would change since  topology name 
reflect the name of topology file. 
e.g.
   http://knox_url:knox_port:/gateway/datanode1
http://knox_url:knox_port:/gateway/datanode2
...

2. Another way to accomplish this is by passing the datanode URL as a query 
parameter and attaching this parameter as
an OUTPUT rewrite.
e.g. 
I am able to get the hostname information and dispatch to a datanode hostname 
but we needed to add an OUTPUT rule (content rewrite) so we can attach the 
hostname parameter to the hrefs on the content.

I've created an OUTPUT rewrite function which can access the input request 
parameters.

An example of a rule would be:

{code:xml}
...



  
  

  
  

  

  

  

  
  
  

  

  
  

  
...
{code}

Which can then be forward to a dispatcher with

{code:xml}
...

   


   

{code








> Need rewrite function to capture href information from single page host to 
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E  Rodriguez
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.13.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of 
> the challenges is that a Web page may have more than one link to other hosts 
> of a given type (e.g. Yarn may have a link to more than one  host) which may 
> be different from the originating one. The main issue here is that Knox maps 
> a single host to a rewrite and service. If the page has multiple hosts of a 
> single type the rewrite rules may not be enough without some extra 
> information. For example, Yarn UI may have links to Node URLs (more than one 
> node) and even through the Yarn page may be rewritten to include the schema, 
> and hostname as a query parameters so the dispatcher is able to fetch the 
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and 
> port attached to their query parameters.   We need a function that given a 
> request to one of the links above can save the information needed to rewrite 
> their request output with the query parameters needed for every response 
> links.
> e.g. 
> if we click link 
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as: 
> “/node/node” to 
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
> 
>   
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
> 
> {code}
> This way then we are not only able to request the page as we do today but the 
> output response would be rewritten to have the information needed to be 
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on 
> the “Host” header still doesn’t provide all the information needed such as 
> the scheme. We have access to the request object so it may be easier to get 
> the information directly from the href request than expecting a header. The 
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 
> section 14.23, only defines host and port. There is no reliable way to get 
> the scheme from the response headers. Thus we can't really make use of the 
> patch since we would still need the function to provide us the scheme 
> function. Also there is still more information we may want 

[jira] [Work started] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts

2017-03-27 Thread Jeffrey E Rodriguez (JIRA)

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

Work on KNOX-751 started by Jeffrey E  Rodriguez.
-
> Need rewrite function to capture href information from single page host to 
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E  Rodriguez
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.13.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of 
> the challenges is that a Web page may have more than one link to other hosts 
> of a given type (e.g. Yarn may have a link to more than one  host) which may 
> be different from the originating one. The main issue here is that Knox maps 
> a single host to a rewrite and service. If the page has multiple hosts of a 
> single type the rewrite rules may not be enough without some extra 
> information. For example, Yarn UI may have links to Node URLs (more than one 
> node) and even through the Yarn page may be rewritten to include the schema, 
> and hostname as a query parameters so the dispatcher is able to fetch the 
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and 
> port attached to their query parameters.   We need a function that given a 
> request to one of the links above can save the information needed to rewrite 
> their request output with the query parameters needed for every response 
> links.
> e.g. 
> if we click link 
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as: 
> “/node/node” to 
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
> 
>   
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
> 
> {code}
> This way then we are not only able to request the page as we do today but the 
> output response would be rewritten to have the information needed to be 
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on 
> the “Host” header still doesn’t provide all the information needed such as 
> the scheme. We have access to the request object so it may be easier to get 
> the information directly from the href request than expecting a header. The 
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 
> section 14.23, only defines host and port. There is no reliable way to get 
> the scheme from the response headers. Thus we can't really make use of the 
> patch since we would still need the function to provide us the scheme 
> function. Also there is still more information we may want such the path and 
> query but those as not as critical to our effort to map all links from Yarn 
> UI at this point.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts

2017-03-27 Thread Jeffrey E Rodriguez (JIRA)

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

Jeffrey E  Rodriguez updated KNOX-751:
--
Attachment: KNOX-751.001.patch

Following patch implements an "output" rewrite function which permits to get 
the query parameter from an IN request and attache the parameter to the 
outbound content.

> Need rewrite function to capture href information from single page host to 
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E  Rodriguez
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.13.0
>
> Attachments: KNOX-751.001.patch
>
>
> User Interface page rewriting through Knox presents many challenges. One of 
> the challenges is that a Web page may have more than one link to other hosts 
> of a given type (e.g. Yarn may have a link to more than one  host) which may 
> be different from the originating one. The main issue here is that Knox maps 
> a single host to a rewrite and service. If the page has multiple hosts of a 
> single type the rewrite rules may not be enough without some extra 
> information. For example, Yarn UI may have links to Node URLs (more than one 
> node) and even through the Yarn page may be rewritten to include the schema, 
> and hostname as a query parameters so the dispatcher is able to fetch the 
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and 
> port attached to their query parameters.   We need a function that given a 
> request to one of the links above can save the information needed to rewrite 
> their request output with the query parameters needed for every response 
> links.
> e.g. 
> if we click link 
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as: 
> “/node/node” to 
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
> 
>   
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
> 
> {code}
> This way then we are not only able to request the page as we do today but the 
> output response would be rewritten to have the information needed to be 
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on 
> the “Host” header still doesn’t provide all the information needed such as 
> the scheme. We have access to the request object so it may be easier to get 
> the information directly from the href request than expecting a header. The 
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 
> section 14.23, only defines host and port. There is no reliable way to get 
> the scheme from the response headers. Thus we can't really make use of the 
> patch since we would still need the function to provide us the scheme 
> function. Also there is still more information we may want such the path and 
> query but those as not as critical to our effort to map all links from Yarn 
> UI at this point.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts

2017-03-27 Thread Jeffrey E Rodriguez (JIRA)

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

Jeffrey E  Rodriguez updated KNOX-751:
--
Status: Patch Available  (was: In Progress)

> Need rewrite function to capture href information from single page host to 
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.9.1, 0.9.0, 0.8.0, 0.7.0
> Environment: All environment support Knox
>Reporter: Jeffrey E  Rodriguez
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.13.0
>
> Attachments: KNOX-751.001.patch
>
>
> User Interface page rewriting through Knox presents many challenges. One of 
> the challenges is that a Web page may have more than one link to other hosts 
> of a given type (e.g. Yarn may have a link to more than one  host) which may 
> be different from the originating one. The main issue here is that Knox maps 
> a single host to a rewrite and service. If the page has multiple hosts of a 
> single type the rewrite rules may not be enough without some extra 
> information. For example, Yarn UI may have links to Node URLs (more than one 
> node) and even through the Yarn page may be rewritten to include the schema, 
> and hostname as a query parameters so the dispatcher is able to fetch the 
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and 
> port attached to their query parameters.   We need a function that given a 
> request to one of the links above can save the information needed to rewrite 
> their request output with the query parameters needed for every response 
> links.
> e.g. 
> if we click link 
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as: 
> “/node/node” to 
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
> 
>   
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
> 
> {code}
> This way then we are not only able to request the page as we do today but the 
> output response would be rewritten to have the information needed to be 
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on 
> the “Host” header still doesn’t provide all the information needed such as 
> the scheme. We have access to the request object so it may be easier to get 
> the information directly from the href request than expecting a header. The 
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 
> section 14.23, only defines host and port. There is no reliable way to get 
> the scheme from the response headers. Thus we can't really make use of the 
> patch since we would still need the function to provide us the scheme 
> function. Also there is still more information we may want such the path and 
> query but those as not as critical to our effort to map all links from Yarn 
> UI at this point.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-878) Fix mailing lists page on the website

2017-03-27 Thread Sandeep More (JIRA)

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

Sandeep More updated KNOX-878:
--
Fix Version/s: 0.13.0

> Fix mailing lists page on the website
> -
>
> Key: KNOX-878
> URL: https://issues.apache.org/jira/browse/KNOX-878
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.13.0
>
> Attachments: KNOX-878.patch
>
>
> The mailing lists page uses an incorrect email address for the commits 
> mailing list ("commit" instead of "commits"). See the attached SVN patch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-503) Tests which include expected unreachable hosts fail with wildcard DNS records

2017-03-27 Thread Sandeep More (JIRA)

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

Sandeep More updated KNOX-503:
--
Fix Version/s: (was: Future)
   0.13.0

> Tests which include expected unreachable hosts fail with wildcard DNS records
> -
>
> Key: KNOX-503
> URL: https://issues.apache.org/jira/browse/KNOX-503
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 0.6.0
>Reporter: Kristopher Kane
>Priority: Minor
> Fix For: 0.13.0
>
> Attachments: KNOX-503-AuditLoggingTest-01.patch, 
> KNOX-503-HttpClientDispatchTest-01.patch, 
> KNOX-503-WebHdfsHaHttpClientDispatchTest-01.patch
>
>
> If the DNS zone of the build host contains wildcard DNS entries 
> (http://en.wikipedia.org/wiki/Wildcard_DNS_record) the following tests will 
> fail because 'unreachable-host' and  'outbound-host' will actually resolve: 
> AuditLoggingTest.java
> HttpClientDispatchTest.java
> WebHdfsHaHttpClientDispatchTest.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-438) Support both templeton and webhcat URLs

2017-03-27 Thread Sandeep More (JIRA)

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

Sandeep More updated KNOX-438:
--
Fix Version/s: (was: Future)
   0.13.0

> Support both templeton and webhcat URLs
> ---
>
> Key: KNOX-438
> URL: https://issues.apache.org/jira/browse/KNOX-438
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 0.5.0
>Reporter: Larry McCay
> Fix For: 0.13.0
>
> Attachments: KNOX-438-2.patch
>
>
> WebHCatDeploymentContributor should add a pattern to the patterns and rules 
> for webhcat. This is a convenience to better align the role in the topology 
> file with the API - even though templeton is still officially used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-816) Make private inner classes static

2017-03-27 Thread Sandeep More (JIRA)

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

Sandeep More updated KNOX-816:
--
Fix Version/s: 0.13.0

> Make private inner classes static
> -
>
> Key: KNOX-816
> URL: https://issues.apache.org/jira/browse/KNOX-816
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.13.0
>
> Attachments: 0001-KNOX-816-Make-private-inner-classes-static.patch
>
>
> As discussed on KNOX-792, this JIRA is a placeholder for a patch to make all 
> private inner classes static for performance reasons.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-169) Test issue for patch test automation via PreCommit-Knox-Build job

2017-03-27 Thread Sandeep More (JIRA)

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

Sandeep More updated KNOX-169:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Test issue for patch test automation via PreCommit-Knox-Build job
> -
>
> Key: KNOX-169
> URL: https://issues.apache.org/jira/browse/KNOX-169
> Project: Apache Knox
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 0.3.0
>Reporter: Kevin Minder
>Assignee: Kevin Minder
>Priority: Minor
>  Labels: build
> Fix For: 0.3.0
>
> Attachments: KNOX-169-004.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-486) Configuration Item gateway.gateway.conf.dir is Obsolete

2017-03-27 Thread Sandeep More (JIRA)

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

Sandeep More updated KNOX-486:
--
Fix Version/s: (was: Future)
   0.13.0

> Configuration Item gateway.gateway.conf.dir is Obsolete
> ---
>
> Key: KNOX-486
> URL: https://issues.apache.org/jira/browse/KNOX-486
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.5.0
>Reporter: Larry McCay
>Assignee: Kevin Minder
> Fix For: 0.13.0
>
> Attachments: KNOX-486.1.patch
>
>
> Configuration Name in gateway-default.xml is not same as the name used in 
> "org.apache.hadoop.gateway.config.impl.GatewayConfigImpl"
> * The deployments directory is no longer found in the conf directory.
> * This config item is not actually referenced anywhere in the server that I 
> see with a quick grep
> * Perhaps we can use this to override the default conf dir location itself?
> * or perhaps it should just be removed
> * GatewayConfigImpl class level javadocs are also obsolete and should be 
> addressed by this effort as well.
> Incorrect Configuration name in gateway-default.xml
> {noformat}
> 
> gateway.gateway.conf.dir
> deployments
> The directory within GATEWAY_HOME that contains gateway 
> topology deployments.
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (KNOX-910) SHA-1 algorithms are now known to be vulnerable to compromise and/or collisions should use SHA-256 - Shiro HashedCredentialsMatcher.

2017-03-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/KNOX-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943752#comment-15943752
 ] 

ASF subversion and git services commented on KNOX-910:
--

Commit ba4ddecec1f84ccf62e18bf54996abbaa212d0ce in knox's branch 
refs/heads/master from [~moresandeep]
[ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=ba4ddec ]

KNOX-910 - Move from SHA-1 to SHA-256 (Jeffrey E Rodriguez via Sandeep More)


> SHA-1 algorithms are now known to be vulnerable to  compromise and/or 
> collisions should use SHA-256 - Shiro  HashedCredentialsMatcher.
> --
>
> Key: KNOX-910
> URL: https://issues.apache.org/jira/browse/KNOX-910
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
> Environment: all
>Reporter: Jeffrey E  Rodriguez
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.13.0
>
> Attachments: KNOX-hashal.001.patch
>
>
> From Shiro HashedCredentialsMatcher , SHA-1 algorithms are now known to be 
> vulnerable to compromise and/or collisions should use SHA-256.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (KNOX-910) SHA-1 algorithms are now known to be vulnerable to compromise and/or collisions should use SHA-256 - Shiro HashedCredentialsMatcher.

2017-03-27 Thread Sandeep More (JIRA)

[ 
https://issues.apache.org/jira/browse/KNOX-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943753#comment-15943753
 ] 

Sandeep More commented on KNOX-910:
---

Thanks for the Patch [~jeffreyr97] !

> SHA-1 algorithms are now known to be vulnerable to  compromise and/or 
> collisions should use SHA-256 - Shiro  HashedCredentialsMatcher.
> --
>
> Key: KNOX-910
> URL: https://issues.apache.org/jira/browse/KNOX-910
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
> Environment: all
>Reporter: Jeffrey E  Rodriguez
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.13.0
>
> Attachments: KNOX-hashal.001.patch
>
>
> From Shiro HashedCredentialsMatcher , SHA-1 algorithms are now known to be 
> vulnerable to compromise and/or collisions should use SHA-256.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-910) SHA-1 algorithms are now known to be vulnerable to compromise and/or collisions should use SHA-256 - Shiro HashedCredentialsMatcher.

2017-03-27 Thread Sandeep More (JIRA)

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

Sandeep More updated KNOX-910:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> SHA-1 algorithms are now known to be vulnerable to  compromise and/or 
> collisions should use SHA-256 - Shiro  HashedCredentialsMatcher.
> --
>
> Key: KNOX-910
> URL: https://issues.apache.org/jira/browse/KNOX-910
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
> Environment: all
>Reporter: Jeffrey E  Rodriguez
>Assignee: Jeffrey E  Rodriguez
> Fix For: 0.13.0
>
> Attachments: KNOX-hashal.001.patch
>
>
> From Shiro HashedCredentialsMatcher , SHA-1 algorithms are now known to be 
> vulnerable to compromise and/or collisions should use SHA-256.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (KNOX-878) Fix mailing lists page on the website

2017-03-27 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/KNOX-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943808#comment-15943808
 ] 

ASF subversion and git services commented on KNOX-878:
--

Commit 1788991 from [~moresandeep]
[ https://svn.apache.org/r1788991 ]

KNOX-878 - Fix incorrect email address for commits on the website (Colm O 
hEigeartaigh via Sandeep More)

> Fix mailing lists page on the website
> -
>
> Key: KNOX-878
> URL: https://issues.apache.org/jira/browse/KNOX-878
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.13.0
>
> Attachments: KNOX-878.patch
>
>
> The mailing lists page uses an incorrect email address for the commits 
> mailing list ("commit" instead of "commits"). See the attached SVN patch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (KNOX-878) Fix mailing lists page on the website

2017-03-27 Thread Sandeep More (JIRA)

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

Sandeep More updated KNOX-878:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks [~coheigea] for the patch, it has been committed.

> Fix mailing lists page on the website
> -
>
> Key: KNOX-878
> URL: https://issues.apache.org/jira/browse/KNOX-878
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.13.0
>
> Attachments: KNOX-878.patch
>
>
> The mailing lists page uses an incorrect email address for the commits 
> mailing list ("commit" instead of "commits"). See the attached SVN patch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)