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

Larry McCay commented on KNOX-1230:
-----------------------------------

Hi [~risdenk] - I am not aware of it causing 401's - what I was able to 
reproduce was a couple things:
 * inability to decrypt the protected query param in redirects to the DN when 
putting or getting files from webhdfs
 * sometimes it sort of decrypted the query param but since the key was somehow 
not exactly right it would mangle the resulting URL such that it would be 
invalid with bogus characters in it
 * also dispatch filters ended up with null values for the httpclient and/or 
dispatch objects

In my test environment, I had to switch to PAM since the DEMO LDAP server 
wasn't handing 100 concurrent (or however many were actually concurrent) 
requests and I was seeing some LDAP connection issues which might have been 
401s had they not been NPEs inside of Shiro.

I highly recommend using PAM instead of LDAP, BTW.

> Many Concurrent Requests to Knox causes URL Mangling
> ----------------------------------------------------
>
>                 Key: KNOX-1230
>                 URL: https://issues.apache.org/jira/browse/KNOX-1230
>             Project: Apache Knox
>          Issue Type: Bug
>          Components: Server
>            Reporter: Larry McCay
>            Assignee: Larry McCay
>            Priority: Major
>             Fix For: 1.1.0
>
>         Attachments: KNOX-1230-001.patch, KNOX-1230-002.patch, test-upload.sh
>
>
> We have had some thread safety issues in both our crypto and dispatch 
> machinery for what appears to be have been a long time - if not forever.
> This patch locks down access to the DefaultKeystoreService, synchronizes the 
> creation and initialization of dispatches and removes most of the state in 
> the ConfigurableEncryptor class. It also moves the responsibility of query 
> string encryption and decryption into the 
> SecureQueryEncrypt/DecryptProcessors themselves rather than leveraging the 
> CryptoService by creating member variables for the required 
> ConfigurableEncryptor.



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

Reply via email to