Closed DvirCyberArk closed 6 years ago
Regarding policy size I think that SDK doesn't need to deal with policy size. SDK here is only wrapper for REST so a customer will receive a proper response from Conjur and will reduce policy size by himself.
Regarding policy timeout May be we need to add an additional call with timeout parameter. WDYT?
Are you supporting concurrency? No
Why no? The Client and Policy objects are both thread safe from concurrent policy loading point of view. The only issue is Conjur itself with policy version issue. So different policies can be loaded simultaneously. For the same policy, once we will have 409 response we can implement retry mechanism for loading.
What does this pull request do? Introducing Conjur policy entity to SDK and allow to call load policy to Conjur Server over REST
What background context can you provide? none
Where should the reviewer start? Maybe manual testing can be a good way to start this review process (uploading .yml file)
How should this be manually tested? Create policy yml file convert it to stream and load it using Client to Conjur EE - check UI if policy loaded correctly in structure and functionality.
Link to build in Jenkins (if appropriate) https://jenkins.conjur.net/view/Conjur%205.x/job/cyberark--conjur-api-dotnet/
Questions:
We have some issues with Policy size and timeout limit? Yes, those will be fixed in a separate PR since we want to align GitHub to our current status of code base.
Why are you ignoring policy response. Great question, for our usecase it can include sensitive information that we don't need/want but for open source maybe we need to change it. WDYF?
Are you supporting concurrency? No.