date:20231120



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

Prashant Satam resolved RANGER-4397.

Resolution: Fixed

> API to get DataShare id,name,description List 
> --
>
> Key: RANGER-4397
> URL: https://issues.apache.org/jira/browse/RANGER-4397
> Project: Ranger
>  Issue Type: Sub-task
>  Components: Ranger
>Reporter: Prashant Satam
>Assignee: Prashant Satam
>Priority: Major
>
> Dataset Details >> Add a Datashare >> List Datashares pop up,
> Need a GET API to get all datashares, based on LIST ACL for current user
> Exclude existing one for which request is is available GRANTED, ACTIVE, 
> REQUESTED states
> Response: id, Name, Descrption
> Request: datasetId, excludeExistingDataShare
> Filter: partial search on datashare name, Pagination



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-4534) Use of Query param GdsPermission with value NONE gives incorrect response for GDS GET APIs

Prashant Satam created RANGER-4534:
--

 Summary: Use of Query param GdsPermission with value NONE gives 
incorrect response for GDS GET APIs
 Key: RANGER-4534
 URL: https://issues.apache.org/jira/browse/RANGER-4534
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Prashant Satam






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (RANGER-4534) Use of Query param GdsPermission with value NONE gives incorrect response for GDS GET APIs



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

Prashant Satam reassigned RANGER-4534:
--

Assignee: Prashant Satam

> Use of Query param GdsPermission with value NONE gives incorrect response for 
> GDS GET APIs
> --
>
> Key: RANGER-4534
> URL: https://issues.apache.org/jira/browse/RANGER-4534
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Prashant Satam
>Assignee: Prashant Satam
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RANGER-4534) Use of Query param GdsPermission with value NONE gives incorrect response for GDS GET APIs



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

Prashant Satam updated RANGER-4534:
---
Description: 
When we use GDS GET APIs for (dataset/datashare/project) and pass query param 
gdsPermission=NONE we get all the objects in response which is not expected

Example : 

1)We have 4 datasets created 

2)Test-User has ADMIN access to 2 datasets only for remaining 2 datasets, 
Test-User has no permission in ACL of dataset 

3)Still when Test-User use GET API ---> /service/gds/dataset with query param 
gdsPermission = NONE he gets all the 4 datasets in response which is not 
expected

> Use of Query param GdsPermission with value NONE gives incorrect response for 
> GDS GET APIs
> --
>
> Key: RANGER-4534
> URL: https://issues.apache.org/jira/browse/RANGER-4534
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Prashant Satam
>Assignee: Prashant Satam
>Priority: Major
>
> When we use GDS GET APIs for (dataset/datashare/project) and pass query param 
> gdsPermission=NONE we get all the objects in response which is not expected
> Example : 
> 1)We have 4 datasets created 
> 2)Test-User has ADMIN access to 2 datasets only for remaining 2 datasets, 
> Test-User has no permission in ACL of dataset 
> 3)Still when Test-User use GET API ---> /service/gds/dataset with query param 
> gdsPermission = NONE he gets all the 4 datasets in response which is not 
> expected



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RANGER-4534) Use of Query param GdsPermission with value NONE gives incorrect response for GDS GET APIs



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

Prashant Satam updated RANGER-4534:
---
Description: 
When we use GDS GET APIs for (dataset/datashare/project) and pass query param 
gdsPermission=NONE we get all the objects in response which is not expected

Example : 

When the param gdsPermission=NONE is passed in request, in the GET APIs e.g. 
GET /gds/dataset, whole dataset list is returned in response, even if the 
calling user is not added in the ACLs in any of the datasets.

  was:
When we use GDS GET APIs for (dataset/datashare/project) and pass query param 
gdsPermission=NONE we get all the objects in response which is not expected

Example : 

1)We have 4 datasets created 

2)Test-User has ADMIN access to 2 datasets only for remaining 2 datasets, 
Test-User has no permission in ACL of dataset 

3)Still when Test-User use GET API ---> /service/gds/dataset with query param 
gdsPermission = NONE he gets all the 4 datasets in response which is not 
expected


> Use of Query param GdsPermission with value NONE gives incorrect response for 
> GDS GET APIs
> --
>
> Key: RANGER-4534
> URL: https://issues.apache.org/jira/browse/RANGER-4534
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Prashant Satam
>Assignee: Prashant Satam
>Priority: Major
>
> When we use GDS GET APIs for (dataset/datashare/project) and pass query param 
> gdsPermission=NONE we get all the objects in response which is not expected
> Example : 
> When the param gdsPermission=NONE is passed in request, in the GET APIs e.g. 
> GET /gds/dataset, whole dataset list is returned in response, even if the 
> calling user is not added in the ACLs in any of the datasets.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RANGER-4438) Read JAVA_OPTS in ranger db setup python script

2023-11-20 Thread Pradeep Agrawal (Jira)



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

Pradeep Agrawal commented on RANGER-4438:
-

Commit link : 
https://github.com/apache/ranger/commit/9146ff44fc5bd7c27ca70c564c02cd98f8ab4a43

> Read JAVA_OPTS in ranger db setup python script
> ---
>
> Key: RANGER-4438
> URL: https://issues.apache.org/jira/browse/RANGER-4438
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Pradeep Agrawal
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 0001-RANGER-4438.patch
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-4535) GET dataset API should return public:LIST in ACL if available

2023-11-20 Thread Subhrat Chaudhary (Jira)

Subhrat Chaudhary created RANGER-4535:
-

 Summary: GET dataset API should return public:LIST in ACL if 
available
 Key: RANGER-4535
 URL: https://issues.apache.org/jira/browse/RANGER-4535
 Project: Ranger
  Issue Type: Sub-task
  Components: admin
Reporter: Subhrat Chaudhary


When the GET dataset /gds/dataset API is called, gdsPermission=LIST is passed 
in query-param, available ACLs are not returned in the dataset.

It will be helpful to know, if the current dataset is accessible to public 
group (which can be eventually used by the depending applications). We can add 
the the ACL, in the returned dataset (if available):
{code:java}
"groups": { "public": "LIST" }{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (RANGER-4535) GET dataset API should return public:LIST in ACL if available

2023-11-20 Thread Subhrat Chaudhary (Jira)



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

Subhrat Chaudhary reassigned RANGER-4535:
-

Assignee: Subhrat Chaudhary

> GET dataset API should return public:LIST in ACL if available
> -
>
> Key: RANGER-4535
> URL: https://issues.apache.org/jira/browse/RANGER-4535
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Subhrat Chaudhary
>Assignee: Subhrat Chaudhary
>Priority: Major
>
> When the GET dataset /gds/dataset API is called, gdsPermission=LIST is passed 
> in query-param, available ACLs are not returned in the dataset.
> It will be helpful to know, if the current dataset is accessible to public 
> group (which can be eventually used by the depending applications). We can 
> add the the ACL, in the returned dataset (if available):
> {code:java}
> "groups": { "public": "LIST" }{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Review Request 74744: RANGER-4535: GET dataset API should return public:LIST in ACL if available

2023-11-20 Thread Subhrat Chaudhary via Review Board


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74744/
---

Review request for ranger, Anand Nadar, Ankita Sinha, Madhan Neethiraj, Monika 
Kachhadiya, Prashant Satam, and Siddhesh Phatak.


Bugs: RANGER-4535
https://issues.apache.org/jira/browse/RANGER-4535


Repository: ranger


Description
---

When the GET dataset /gds/dataset API is called, gdsPermission=LIST is passed 
in query-param, available ACLs are not returned in the dataset.

It will be helpful to know, if the current dataset is accessible to public 
group, in case gdsPermission=LIST is passed in query-param (which can be 
eventually used by the depending applications). We can add the the ACL, in the 
returned dataset (if available):

"groups": { "public": "LIST" }


Diffs
-

  security-admin/src/main/java/org/apache/ranger/biz/GdsDBStore.java 589fcdd68 
  
security-admin/src/main/java/org/apache/ranger/validation/RangerGdsValidator.java
 6c55fd029 


Diff: https://reviews.apache.org/r/74744/diff/1/


Testing
---

Following cases are validated (with gdsPermission=LIST passed in query-param) 
(tested with GET /gds/dataset API):
1. Even if the calling user has higher than LIST access, same is not retruned 
in ACL.
2. All the datasets where public : LIST access is given, are returned in 
response.
3. When the API is called by ranger admin user, all the datasets are returned 
and only public : LIST permission is available in the ACL (no other permissions 
are added in the ACL, even if the user has them in the dataset).


Thanks,

Subhrat Chaudhary

Re: Review Request 74744: RANGER-4535: GET dataset API should return public:LIST in ACL if available


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74744/#review225974
---




security-admin/src/main/java/org/apache/ranger/biz/GdsDBStore.java
Lines 1494 (patched)


getScrubbedAcl() ==> getPublicAclIfAllowed()



security-admin/src/main/java/org/apache/ranger/biz/GdsDBStore.java
Lines 1497 (patched)


Wouldn't it be useful to return the permission for public group, instead of 
just LIST permission?


- Madhan Neethiraj


On Nov. 20, 2023, 2:14 p.m., Subhrat Chaudhary wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74744/
> ---
> 
> (Updated Nov. 20, 2023, 2:14 p.m.)
> 
> 
> Review request for ranger, Anand Nadar, Ankita Sinha, Madhan Neethiraj, 
> Monika Kachhadiya, Prashant Satam, and Siddhesh Phatak.
> 
> 
> Bugs: RANGER-4535
> https://issues.apache.org/jira/browse/RANGER-4535
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> When the GET dataset /gds/dataset API is called, gdsPermission=LIST is passed 
> in query-param, available ACLs are not returned in the dataset.
> 
> It will be helpful to know, if the current dataset is accessible to public 
> group, in case gdsPermission=LIST is passed in query-param (which can be 
> eventually used by the depending applications). We can add the the ACL, in 
> the returned dataset (if available):
> 
> "groups": { "public": "LIST" }
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/GdsDBStore.java 
> 589fcdd68 
>   
> security-admin/src/main/java/org/apache/ranger/validation/RangerGdsValidator.java
>  6c55fd029 
> 
> 
> Diff: https://reviews.apache.org/r/74744/diff/1/
> 
> 
> Testing
> ---
> 
> Following cases are validated (with gdsPermission=LIST passed in query-param) 
> (tested with GET /gds/dataset API):
> 1. Even if the calling user has higher than LIST access, same is not retruned 
> in ACL.
> 2. All the datasets where public : LIST access is given, are returned in 
> response.
> 3. When the API is called by ranger admin user, all the datasets are returned 
> and only public : LIST permission is available in the ACL (no other 
> permissions are added in the ACL, even if the user has them in the dataset).
> 
> 
> Thanks,
> 
> Subhrat Chaudhary
> 
>

Re: Review Request 74744: RANGER-4535: GET dataset API should return public:LIST in ACL if available

2023-11-20 Thread Subhrat Chaudhary via Review Board


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74744/
---

(Updated Nov. 20, 2023, 10:05 p.m.)


Review request for ranger, Anand Nadar, Ankita Sinha, Madhan Neethiraj, Monika 
Kachhadiya, Prashant Satam, and Siddhesh Phatak.


Changes
---

Addressed review comments.


Bugs: RANGER-4535
https://issues.apache.org/jira/browse/RANGER-4535


Repository: ranger


Description
---

When the GET dataset /gds/dataset API is called, gdsPermission=LIST is passed 
in query-param, available ACLs are not returned in the dataset.

It will be helpful to know, if the current dataset is accessible to public 
group, in case gdsPermission=LIST is passed in query-param (which can be 
eventually used by the depending applications). We can add the the ACL, in the 
returned dataset (if available):

"groups": { "public": "LIST" }


Diffs (updated)
-

  security-admin/src/main/java/org/apache/ranger/biz/GdsDBStore.java 589fcdd68 
  
security-admin/src/main/java/org/apache/ranger/validation/RangerGdsValidator.java
 6c55fd029 


Diff: https://reviews.apache.org/r/74744/diff/2/

Changes: https://reviews.apache.org/r/74744/diff/1-2/


Testing
---

Following cases are validated (with gdsPermission=LIST passed in query-param) 
(tested with GET /gds/dataset API):
1. Even if the calling user has higher than LIST access, same is not retruned 
in ACL.
2. All the datasets where public : LIST access is given, are returned in 
response.
3. When the API is called by ranger admin user, all the datasets are returned 
and only public : LIST permission is available in the ACL (no other permissions 
are added in the ACL, even if the user has them in the dataset).


Thanks,

Subhrat Chaudhary

Re: Review Request 74744: RANGER-4535: GET dataset API should return public:LIST in ACL if available

2023-11-20 Thread Subhrat Chaudhary via Review Board


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74744/
---

(Updated Nov. 20, 2023, 10:06 p.m.)


Review request for ranger, Anand Nadar, Ankita Sinha, Madhan Neethiraj, Monika 
Kachhadiya, Prashant Satam, and Siddhesh Phatak.


Bugs: RANGER-4535
https://issues.apache.org/jira/browse/RANGER-4535


Repository: ranger


Description
---

When the GET dataset /gds/dataset API is called, gdsPermission=LIST is passed 
in query-param, available ACLs are not returned in the dataset.

It will be helpful to know, if the current dataset is accessible to public 
group, in case gdsPermission=LIST is passed in query-param (which can be 
eventually used by the depending applications). We can add the the ACL, in the 
returned dataset (if available):

"groups": { "public": "LIST" }


Diffs
-

  security-admin/src/main/java/org/apache/ranger/biz/GdsDBStore.java 589fcdd68 
  
security-admin/src/main/java/org/apache/ranger/validation/RangerGdsValidator.java
 6c55fd029 


Diff: https://reviews.apache.org/r/74744/diff/2/


Testing (updated)
---

Following cases are validated (with gdsPermission=LIST passed in query-param) 
(tested with GET /gds/dataset API):
1. Even if the calling user has higher than LIST access, same is not retruned 
in ACL.
2. All the datasets where public : LIST access is given, are returned in 
response.
3. When the API is called by ranger admin user, all the datasets are returned 
and only permission for public group is returned in the ACL (no other 
permissions are added in the ACL, even if the user has them in the dataset).


Thanks,

Subhrat Chaudhary

[jira] [Assigned] (RANGER-4282) Audit log to capture datasets and projects



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

Madhan Neethiraj reassigned RANGER-4282:


Assignee: Madhan Neethiraj

> Audit log to capture datasets and projects
> --
>
> Key: RANGER-4282
> URL: https://issues.apache.org/jira/browse/RANGER-4282
> Project: Ranger
>  Issue Type: Sub-task
>  Components: audit
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
>
> With the introduction of GDS, it will be critical for access audit log 
> generated by Ranger plugin to include list of datasets the accessed resource 
> belongs to. In addition to enhancements in access audit data structure, Solr 
> schema and UI should be updated to handle new field(s).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-4536) Audit UI updates to support datasets and projects

Madhan Neethiraj created RANGER-4536:


 Summary: Audit UI updates to support datasets and projects
 Key: RANGER-4536
 URL: https://issues.apache.org/jira/browse/RANGER-4536
 Project: Ranger
  Issue Type: Sub-task
  Components: admin, audit
Reporter: Madhan Neethiraj


With RANGER-4282, Ranger audit logs were updated to store datasets and 
projects. Audit UI should be updated to:
 * add 2 columns in the table listing audit logs
 * support filtering of audit logs based on dataset and projects

 

CC: [~Dhaval.Rajpara], [~brijesh.bhalala], [~anandNadar]  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Review Request 74745: RANGER-4282: updated audit logs to capture datasets and projects


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74745/
---

Review request for ranger, Anand Nadar, Ankita Sinha, Brijesh Bhalala, Dhaval 
Rajpara, Abhay Kulkarni, Mehul Parikh, Monika Kachhadiya, Mugdha Varadkar, 
Ramesh Mani, Subhrat Chaudhary, and Velmurugan Periasamy.


Bugs: RANGER-4282
https://issues.apache.org/jira/browse/RANGER-4282


Repository: ranger


Description
---

- updated AuthzAuditEvent with 2 new fields: datasets, projects
- updated plugin to populate these 2 new fields in generated audit logs
- updated Solr and Elasticsearch schema to add new fields
- RANGER-4536 tracks audit UI updates to support the new fields


Diffs
-

  
agents-audit/src/main/java/org/apache/ranger/audit/destination/ElasticSearchAuditDestination.java
 1b17a934b 
  
agents-audit/src/main/java/org/apache/ranger/audit/destination/SolrAuditDestination.java
 f2e96bf9b 
  agents-audit/src/main/java/org/apache/ranger/audit/model/AuthzAuditEvent.java 
e20d1a786 
  
agents-audit/src/main/java/org/apache/ranger/audit/provider/solr/SolrAuditProvider.java
 9cda3f8f3 
  
agents-common/src/main/java/org/apache/ranger/plugin/audit/RangerDefaultAuditHandler.java
 c99465d7a 
  dev-support/ranger-docker/config/solr-ranger_audits/managed-schema c33f6de06 
  
security-admin/contrib/elasticsearch_for_audit_setup/conf/ranger_es_schema.json 
801667bce 
  security-admin/contrib/solr_for_audit_setup/conf/managed-schema c33f6de06 
  
security-admin/src/main/java/org/apache/ranger/amazon/cloudwatch/CloudWatchAccessAuditsService.java
 0b36f6e90 
  
security-admin/src/main/java/org/apache/ranger/elasticsearch/ElasticSearchAccessAuditsService.java
 4c9b049a0 
  
security-admin/src/main/java/org/apache/ranger/service/XAccessAuditService.java 
4d96df6ea 
  
security-admin/src/main/java/org/apache/ranger/solr/SolrAccessAuditsService.java
 bb279349a 
  security-admin/src/main/java/org/apache/ranger/view/VXAccessAudit.java 
cce18fafb 


Diff: https://reviews.apache.org/r/74745/diff/1/


Testing
---

- verified audit logs written to Solr include datasets and projects associated 
with the resource
- verified audit logs retrieved via REST API calls include datasets and projects


Thanks,

Madhan Neethiraj

[jira] [Updated] (RANGER-4282) Audit log to capture datasets and projects



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

Madhan Neethiraj updated RANGER-4282:
-
Attachment: RANGER-4282.patch

> Audit log to capture datasets and projects
> --
>
> Key: RANGER-4282
> URL: https://issues.apache.org/jira/browse/RANGER-4282
> Project: Ranger
>  Issue Type: Sub-task
>  Components: audit
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: RANGER-4282.patch
>
>
> With the introduction of GDS, it will be critical for access audit log 
> generated by Ranger plugin to include list of datasets the accessed resource 
> belongs to. In addition to enhancements in access audit data structure, Solr 
> schema and UI should be updated to handle new field(s).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-4537) upgrade audit schema ,in Solr and Elasticsearch, to support datasets and projects

Madhan Neethiraj created RANGER-4537:


 Summary: upgrade audit schema ,in Solr and Elasticsearch, to 
support datasets and projects
 Key: RANGER-4537
 URL: https://issues.apache.org/jira/browse/RANGER-4537
 Project: Ranger
  Issue Type: Sub-task
  Components: audit
Reporter: Madhan Neethiraj


RANGER-4282 updated audit logs to capture datasets and projects associated with 
the accessed resource. This Jira is to track updating of existing Solr 
collection (and corresponding one in Elasticsearch) with fields for datasets 
and projects.

CC: [~ankita], [~monika.kachhadiya], [~suchnit] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74745: RANGER-4282: updated audit logs to capture datasets and projects

2023-11-20 Thread Ramesh Mani


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74745/#review225975
---




agents-audit/src/main/java/org/apache/ranger/audit/model/AuthzAuditEvent.java
Line 112 (original), 112 (patched)


Does this fields need to be in Ranger UI, then we need to have another JIRA 
to update it.



security-admin/src/main/java/org/apache/ranger/service/XAccessAuditService.java
Lines 133 (patched)


Commented-out statement, if not needed please remove.


- Ramesh Mani


On Nov. 20, 2023, 11:32 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74745/
> ---
> 
> (Updated Nov. 20, 2023, 11:32 p.m.)
> 
> 
> Review request for ranger, Anand Nadar, Ankita Sinha, Brijesh Bhalala, Dhaval 
> Rajpara, Abhay Kulkarni, Mehul Parikh, Monika Kachhadiya, Mugdha Varadkar, 
> Ramesh Mani, Subhrat Chaudhary, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4282
> https://issues.apache.org/jira/browse/RANGER-4282
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> - updated AuthzAuditEvent with 2 new fields: datasets, projects
> - updated plugin to populate these 2 new fields in generated audit logs
> - updated Solr and Elasticsearch schema to add new fields
> - RANGER-4536 tracks audit UI updates to support the new fields
> 
> 
> Diffs
> -
> 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/destination/ElasticSearchAuditDestination.java
>  1b17a934b 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/destination/SolrAuditDestination.java
>  f2e96bf9b 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/model/AuthzAuditEvent.java 
> e20d1a786 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/provider/solr/SolrAuditProvider.java
>  9cda3f8f3 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/audit/RangerDefaultAuditHandler.java
>  c99465d7a 
>   dev-support/ranger-docker/config/solr-ranger_audits/managed-schema 
> c33f6de06 
>   
> security-admin/contrib/elasticsearch_for_audit_setup/conf/ranger_es_schema.json
>  801667bce 
>   security-admin/contrib/solr_for_audit_setup/conf/managed-schema c33f6de06 
>   
> security-admin/src/main/java/org/apache/ranger/amazon/cloudwatch/CloudWatchAccessAuditsService.java
>  0b36f6e90 
>   
> security-admin/src/main/java/org/apache/ranger/elasticsearch/ElasticSearchAccessAuditsService.java
>  4c9b049a0 
>   
> security-admin/src/main/java/org/apache/ranger/service/XAccessAuditService.java
>  4d96df6ea 
>   
> security-admin/src/main/java/org/apache/ranger/solr/SolrAccessAuditsService.java
>  bb279349a 
>   security-admin/src/main/java/org/apache/ranger/view/VXAccessAudit.java 
> cce18fafb 
> 
> 
> Diff: https://reviews.apache.org/r/74745/diff/1/
> 
> 
> Testing
> ---
> 
> - verified audit logs written to Solr include datasets and projects 
> associated with the resource
> - verified audit logs retrieved via REST API calls include datasets and 
> projects
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 74739: RANGER-4529: optimized script condition evaluator to avoid creation of multiple bindings

2023-11-20 Thread Abhay Kulkarni


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74739/#review225976
---




agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerRequestScriptEvaluator.java
Line 225 (original), 205 (patched)


Why is the safe execution prefix is removed in the new code?


- Abhay Kulkarni


On Nov. 14, 2023, 8:44 a.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74739/
> ---
> 
> (Updated Nov. 14, 2023, 8:44 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Abhay Kulkarni, Mehul Parikh, Monika 
> Kachhadiya, Ramesh Mani, Sailaja Polavarapu, Subhrat Chaudhary, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4529
> https://issues.apache.org/jira/browse/RANGER-4529
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> moved creation of bindings from RangerRequestScriptEvaluator.evaluateScript() 
> to constructor, so that bindings will be reused across multiple calls to 
> evaluateScript()
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerAnyOfExpectedTagsPresentConditionEvaluator.java
>  bf57fb412 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerNoneOfExpectedTagsPresentConditionEvaluator.java
>  938836f66 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerScriptConditionEvaluator.java
>  80a766566 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerTagsAllPresentConditionEvaluator.java
>  82b59d24b 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerRequestScriptEvaluator.java
>  2c1fe2ac1 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerCommonConstants.java
>  8081dd346 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerRequestExprResolver.java
>  9440d7676 
>   
> agents-common/src/test/java/org/apache/ranger/plugin/conditionevaluator/RangerRequestScriptEvaluatorTest.java
>  d3e343480 
>   
> agents-common/src/test/java/org/apache/ranger/plugin/util/RangerRequestExprResolverTest.java
>  6d5edc04c 
> 
> 
> Diff: https://reviews.apache.org/r/74739/diff/1/
> 
> 
> Testing
> ---
> 
> - verified that all existing tests pass successfully
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 74739: RANGER-4529: optimized script condition evaluator to avoid creation of multiple bindings


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74739/#review225977
---




agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerRequestScriptEvaluator.java
Line 225 (original), 205 (patched)


SCRIPT_SAFE_PREEXEC is included while executing the script provided by the 
user - #248 below.

#210, in the constructor, executes only the script that sets up 
SCRIPT_VAR__CTX_JSON. Hence including SCRIPT_SAFE_PREEXEC is not necessary.


- Madhan Neethiraj


On Nov. 14, 2023, 8:44 a.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74739/
> ---
> 
> (Updated Nov. 14, 2023, 8:44 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Abhay Kulkarni, Mehul Parikh, Monika 
> Kachhadiya, Ramesh Mani, Sailaja Polavarapu, Subhrat Chaudhary, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4529
> https://issues.apache.org/jira/browse/RANGER-4529
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> moved creation of bindings from RangerRequestScriptEvaluator.evaluateScript() 
> to constructor, so that bindings will be reused across multiple calls to 
> evaluateScript()
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerAnyOfExpectedTagsPresentConditionEvaluator.java
>  bf57fb412 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerNoneOfExpectedTagsPresentConditionEvaluator.java
>  938836f66 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerScriptConditionEvaluator.java
>  80a766566 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerTagsAllPresentConditionEvaluator.java
>  82b59d24b 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerRequestScriptEvaluator.java
>  2c1fe2ac1 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerCommonConstants.java
>  8081dd346 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerRequestExprResolver.java
>  9440d7676 
>   
> agents-common/src/test/java/org/apache/ranger/plugin/conditionevaluator/RangerRequestScriptEvaluatorTest.java
>  d3e343480 
>   
> agents-common/src/test/java/org/apache/ranger/plugin/util/RangerRequestExprResolverTest.java
>  6d5edc04c 
> 
> 
> Diff: https://reviews.apache.org/r/74739/diff/1/
> 
> 
> Testing
> ---
> 
> - verified that all existing tests pass successfully
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 74739: RANGER-4529: optimized script condition evaluator to avoid creation of multiple bindings



> On Nov. 21, 2023, 1:03 a.m., Abhay Kulkarni wrote:
> > agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerRequestScriptEvaluator.java
> > Line 225 (original), 205 (patched)
> > 
> >
> > Why is the safe execution prefix is removed in the new code?

SCRIPT_SAFE_PREEXEC is included while executing the script provided by the user 
- #248 below.


Line #210, in the constructor, executes only the script that sets up 
SCRIPT_VAR__CTX_JSON. Hence including SCRIPT_SAFE_PREEXEC is not necessary.


- Madhan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74739/#review225976
---


On Nov. 14, 2023, 8:44 a.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74739/
> ---
> 
> (Updated Nov. 14, 2023, 8:44 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Abhay Kulkarni, Mehul Parikh, Monika 
> Kachhadiya, Ramesh Mani, Sailaja Polavarapu, Subhrat Chaudhary, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4529
> https://issues.apache.org/jira/browse/RANGER-4529
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> moved creation of bindings from RangerRequestScriptEvaluator.evaluateScript() 
> to constructor, so that bindings will be reused across multiple calls to 
> evaluateScript()
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerAnyOfExpectedTagsPresentConditionEvaluator.java
>  bf57fb412 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerNoneOfExpectedTagsPresentConditionEvaluator.java
>  938836f66 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerScriptConditionEvaluator.java
>  80a766566 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerTagsAllPresentConditionEvaluator.java
>  82b59d24b 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerRequestScriptEvaluator.java
>  2c1fe2ac1 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerCommonConstants.java
>  8081dd346 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerRequestExprResolver.java
>  9440d7676 
>   
> agents-common/src/test/java/org/apache/ranger/plugin/conditionevaluator/RangerRequestScriptEvaluatorTest.java
>  d3e343480 
>   
> agents-common/src/test/java/org/apache/ranger/plugin/util/RangerRequestExprResolverTest.java
>  6d5edc04c 
> 
> 
> Diff: https://reviews.apache.org/r/74739/diff/1/
> 
> 
> Testing
> ---
> 
> - verified that all existing tests pass successfully
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 74745: RANGER-4282: updated audit logs to capture datasets and projects



> On Nov. 21, 2023, 12:34 a.m., Ramesh Mani wrote:
> > agents-audit/src/main/java/org/apache/ranger/audit/model/AuthzAuditEvent.java
> > Line 112 (original), 112 (patched)
> > 
> >
> > Does this fields need to be in Ranger UI, then we need to have another 
> > JIRA to update it.

Yes, Ramesh. Audit UI should be updated for the addition of these 2 new fields. 
Filed RANGER-4536 to track UI updates.


> On Nov. 21, 2023, 12:34 a.m., Ramesh Mani wrote:
> > security-admin/src/main/java/org/apache/ranger/service/XAccessAuditService.java
> > Lines 133 (patched)
> > 
> >
> > Commented-out statement, if not needed please remove.

XXAcccessAudit table is no more used in Ranger. We should actually remove 
classes related to this table from master branch (3.0 release). In the 
meantime, I will update this patch to revert changes in this file.


- Madhan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74745/#review225975
---


On Nov. 20, 2023, 11:32 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74745/
> ---
> 
> (Updated Nov. 20, 2023, 11:32 p.m.)
> 
> 
> Review request for ranger, Anand Nadar, Ankita Sinha, Brijesh Bhalala, Dhaval 
> Rajpara, Abhay Kulkarni, Mehul Parikh, Monika Kachhadiya, Mugdha Varadkar, 
> Ramesh Mani, Subhrat Chaudhary, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4282
> https://issues.apache.org/jira/browse/RANGER-4282
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> - updated AuthzAuditEvent with 2 new fields: datasets, projects
> - updated plugin to populate these 2 new fields in generated audit logs
> - updated Solr and Elasticsearch schema to add new fields
> - RANGER-4536 tracks audit UI updates to support the new fields
> 
> 
> Diffs
> -
> 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/destination/ElasticSearchAuditDestination.java
>  1b17a934b 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/destination/SolrAuditDestination.java
>  f2e96bf9b 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/model/AuthzAuditEvent.java 
> e20d1a786 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/provider/solr/SolrAuditProvider.java
>  9cda3f8f3 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/audit/RangerDefaultAuditHandler.java
>  c99465d7a 
>   dev-support/ranger-docker/config/solr-ranger_audits/managed-schema 
> c33f6de06 
>   
> security-admin/contrib/elasticsearch_for_audit_setup/conf/ranger_es_schema.json
>  801667bce 
>   security-admin/contrib/solr_for_audit_setup/conf/managed-schema c33f6de06 
>   
> security-admin/src/main/java/org/apache/ranger/amazon/cloudwatch/CloudWatchAccessAuditsService.java
>  0b36f6e90 
>   
> security-admin/src/main/java/org/apache/ranger/elasticsearch/ElasticSearchAccessAuditsService.java
>  4c9b049a0 
>   
> security-admin/src/main/java/org/apache/ranger/service/XAccessAuditService.java
>  4d96df6ea 
>   
> security-admin/src/main/java/org/apache/ranger/solr/SolrAccessAuditsService.java
>  bb279349a 
>   security-admin/src/main/java/org/apache/ranger/view/VXAccessAudit.java 
> cce18fafb 
> 
> 
> Diff: https://reviews.apache.org/r/74745/diff/1/
> 
> 
> Testing
> ---
> 
> - verified audit logs written to Solr include datasets and projects 
> associated with the resource
> - verified audit logs retrieved via REST API calls include datasets and 
> projects
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 74739: RANGER-4529: optimized script condition evaluator to avoid creation of multiple bindings

2023-11-20 Thread Abhay Kulkarni


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74739/#review225980
---


Ship it!




Ship It!

- Abhay Kulkarni


On Nov. 14, 2023, 8:44 a.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74739/
> ---
> 
> (Updated Nov. 14, 2023, 8:44 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Abhay Kulkarni, Mehul Parikh, Monika 
> Kachhadiya, Ramesh Mani, Sailaja Polavarapu, Subhrat Chaudhary, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4529
> https://issues.apache.org/jira/browse/RANGER-4529
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> moved creation of bindings from RangerRequestScriptEvaluator.evaluateScript() 
> to constructor, so that bindings will be reused across multiple calls to 
> evaluateScript()
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerAnyOfExpectedTagsPresentConditionEvaluator.java
>  bf57fb412 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerNoneOfExpectedTagsPresentConditionEvaluator.java
>  938836f66 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerScriptConditionEvaluator.java
>  80a766566 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/conditionevaluator/RangerTagsAllPresentConditionEvaluator.java
>  82b59d24b 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerRequestScriptEvaluator.java
>  2c1fe2ac1 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerCommonConstants.java
>  8081dd346 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerRequestExprResolver.java
>  9440d7676 
>   
> agents-common/src/test/java/org/apache/ranger/plugin/conditionevaluator/RangerRequestScriptEvaluatorTest.java
>  d3e343480 
>   
> agents-common/src/test/java/org/apache/ranger/plugin/util/RangerRequestExprResolverTest.java
>  6d5edc04c 
> 
> 
> Diff: https://reviews.apache.org/r/74739/diff/1/
> 
> 
> Testing
> ---
> 
> - verified that all existing tests pass successfully
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 74701: RANGER-4493: Keep the UI behaviour for tag based and resource based services filtering for zone without any service

2023-11-20 Thread Mugdha Varadkar


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74701/#review225981
---


Ship it!




Ship It!

- Mugdha Varadkar


On Nov. 20, 2023, 6:53 a.m., Brijesh Bhalala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74701/
> ---
> 
> (Updated Nov. 20, 2023, 6:53 a.m.)
> 
> 
> Review request for ranger, Dhaval Rajpara and Mugdha Varadkar.
> 
> 
> Bugs: RANGER-4493
> https://issues.apache.org/jira/browse/RANGER-4493
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> In Ranger admin, security zones can be now created without any 
> services/resources.
> If a security zone is created without any service, and on the service manager 
> page,
> if the resource based services are filtered based on the zone without any 
> service,
> then the UI displays an image with the text "No Services".
> But if the same service filtering is done for tag based services, then the UI 
> shows a service element for tag.
> It will be better if the UI behaviour is consistent for both resource and tag 
> based service filtering
> 
> In the current review request, I have improvise the code with following fixes 
> :
> 
> 1)Fix for the No service page in tag based.
> 2)Fix for the deleting the zone service while filtering zone.
> 3)Fix for import and export button click when there are no service while 
> filtering zone.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/react-webapp/src/views/Home.jsx 67f71ec79 
>   
> security-admin/src/main/webapp/react-webapp/src/views/ServiceManager/ServiceDefinitions.jsx
>  8c222d080 
>   
> security-admin/src/main/webapp/react-webapp/src/views/ServiceManager/ServiceForm.jsx
>  47763fb9d 
>   security-admin/src/main/webapp/react-webapp/src/views/SideBar/TopNavBar.jsx 
> d4dbc57d1 
> 
> 
> Diff: https://reviews.apache.org/r/74701/diff/3/
> 
> 
> Testing
> ---
> 
> Testing is in progress
> 
> 
> Thanks,
> 
> Brijesh Bhalala
> 
>

[jira] [Created] (RANGER-4538) Plugin status should track GDS info download details as well

Madhan Neethiraj created RANGER-4538:


 Summary: Plugin status should track GDS info download details as 
well
 Key: RANGER-4538
 URL: https://issues.apache.org/jira/browse/RANGER-4538
 Project: Ranger
  Issue Type: Sub-task
  Components: admin
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


Ranger admin tracks each plugin's downloading of following details: policies, 
tags, userstore, roles. This should be extended to track GDS info as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74727: RANGER-4187: Not able to search using multiple user filter in access audit tab

2023-11-20 Thread Mugdha Varadkar


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74727/
---

(Updated Nov. 21, 2023, 5:45 a.m.)


Review request for ranger, Brijesh Bhalala, Dhaval Rajpara, and Nikunj 
Pansuriya.


Bugs: RANGER-4187
https://issues.apache.org/jira/browse/RANGER-4187


Repository: ranger


Description
---

This review request is providing a fix to support multiple user search filter 
in Ranger React structured filter.

Steps to reproduce the issue :
1. Go to access audit tab
2. Search with one user
3. Try selecting user filter again
At step 3 user filter is option is not available in the filter


Diffs
-

  
security-admin/src/main/webapp/react-webapp/src/components/structured-filter/react-typeahead/tokenizer/index.js
 82f73024a 
  security-admin/src/main/webapp/react-webapp/src/utils/XAUtils.js ebf1b3fc2 
  
security-admin/src/main/webapp/react-webapp/src/views/AuditEvent/AccessLogs.jsx 
7ec8503e7 


Diff: https://reviews.apache.org/r/74727/diff/2/


Testing (updated)
---

Tested changes on a cluster setup with Ranger Admin build with React JS code 
base.
Verified from Ranger Admin UI > Audits > Access Tab search filter, user can now 
use multiple user, exclude user search filters


Successful completion of build command :
mvn clean compile package


Thanks,

Mugdha Varadkar

Re: Review Request 74727: RANGER-4187: Not able to search using multiple user filter in access audit tab

2023-11-20 Thread Dhaval Rajpara


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74727/#review225982
---


Ship it!




Ship It!

- Dhaval Rajpara


On Nov. 21, 2023, 5:45 a.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74727/
> ---
> 
> (Updated Nov. 21, 2023, 5:45 a.m.)
> 
> 
> Review request for ranger, Brijesh Bhalala, Dhaval Rajpara, and Nikunj 
> Pansuriya.
> 
> 
> Bugs: RANGER-4187
> https://issues.apache.org/jira/browse/RANGER-4187
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> This review request is providing a fix to support multiple user search filter 
> in Ranger React structured filter.
> 
> Steps to reproduce the issue :
> 1. Go to access audit tab
> 2. Search with one user
> 3. Try selecting user filter again
> At step 3 user filter is option is not available in the filter
> 
> 
> Diffs
> -
> 
>   
> security-admin/src/main/webapp/react-webapp/src/components/structured-filter/react-typeahead/tokenizer/index.js
>  82f73024a 
>   security-admin/src/main/webapp/react-webapp/src/utils/XAUtils.js ebf1b3fc2 
>   
> security-admin/src/main/webapp/react-webapp/src/views/AuditEvent/AccessLogs.jsx
>  7ec8503e7 
> 
> 
> Diff: https://reviews.apache.org/r/74727/diff/2/
> 
> 
> Testing
> ---
> 
> Tested changes on a cluster setup with Ranger Admin build with React JS code 
> base.
> Verified from Ranger Admin UI > Audits > Access Tab search filter, user can 
> now use multiple user, exclude user search filters
> 
> 
> Successful completion of build command :
> mvn clean compile package
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

Re: Review Request 74727: RANGER-4187: Not able to search using multiple user filter in access audit tab

2023-11-20 Thread Brijesh Bhalala


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74727/#review225983
---


Ship it!




Ship It!

- Brijesh Bhalala


On Nov. 21, 2023, 5:45 a.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74727/
> ---
> 
> (Updated Nov. 21, 2023, 5:45 a.m.)
> 
> 
> Review request for ranger, Brijesh Bhalala, Dhaval Rajpara, and Nikunj 
> Pansuriya.
> 
> 
> Bugs: RANGER-4187
> https://issues.apache.org/jira/browse/RANGER-4187
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> This review request is providing a fix to support multiple user search filter 
> in Ranger React structured filter.
> 
> Steps to reproduce the issue :
> 1. Go to access audit tab
> 2. Search with one user
> 3. Try selecting user filter again
> At step 3 user filter is option is not available in the filter
> 
> 
> Diffs
> -
> 
>   
> security-admin/src/main/webapp/react-webapp/src/components/structured-filter/react-typeahead/tokenizer/index.js
>  82f73024a 
>   security-admin/src/main/webapp/react-webapp/src/utils/XAUtils.js ebf1b3fc2 
>   
> security-admin/src/main/webapp/react-webapp/src/views/AuditEvent/AccessLogs.jsx
>  7ec8503e7 
> 
> 
> Diff: https://reviews.apache.org/r/74727/diff/2/
> 
> 
> Testing
> ---
> 
> Tested changes on a cluster setup with Ranger Admin build with React JS code 
> base.
> Verified from Ranger Admin UI > Audits > Access Tab search filter, user can 
> now use multiple user, exclude user search filters
> 
> 
> Successful completion of build command :
> mvn clean compile package
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

[jira] [Commented] (RANGER-4524) FIx TestRangerMetricsContainerSource class UT

2023-11-20 Thread Dhaval Shah (Jira)



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

Dhaval Shah commented on RANGER-4524:
-

Hi [~bpatel],

Please share the Review Request link.

Thanks

> FIx TestRangerMetricsContainerSource class UT
> -
>
> Key: RANGER-4524
> URL: https://issues.apache.org/jira/browse/RANGER-4524
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 
> 0001-RANGER-4524-Fix-TestRangerMetricsContainerSource-cla.patch
>
>
> Steps to reproduce:
> 1. clean .m2 repo and trigger the test-cases.
> {code:java}
> java.lang.NoClassDefFoundError: org/apache/log4j/Level at 
> org.apache.ranger.metrics.source.TestRangerMetricsContainerSource.init(TestRangerMetricsContainerSource.java:46)
>  Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Level at 
> org.apache.ranger.metrics.source.TestRangerMetricsContainerSource.init(TestRangerMetricsContainerSource.java:46){code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Review Request 74746: RANGER-4538: updated plugin-status to record GDS info download details


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74746/
---

Review request for ranger, Anand Nadar, Ankita Sinha, Brijesh Bhalala, Dhaval 
Rajpara, Abhay Kulkarni, Monika Kachhadiya, Ramesh Mani, Subhrat Chaudhary, and 
Velmurugan Periasamy.


Bugs: RANGER-4538
https://issues.apache.org/jira/browse/RANGER-4538


Repository: ranger


Description
---

updated GDS info download API to record download details in plugin status


Diffs
-

  
agents-common/src/main/java/org/apache/ranger/plugin/model/RangerPluginInfo.java
 238a98242 
  security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 8bbeba783 
  security-admin/src/main/java/org/apache/ranger/rest/GdsREST.java 1c312e5e9 
  
security-admin/src/main/java/org/apache/ranger/service/RangerPluginInfoService.java
 3a4746def 


Diff: https://reviews.apache.org/r/74746/diff/1/


Testing
---

- verified that GDS download details are stored in column x_plugin_info.info:
{
"pluginCapabilities":  "f",
"adminCapabilities":   "f",
"roleDownloadedVersion":   "1",
"roleDownloadTime":"1700517922727",
"roleActiveVersion":   "-1",
"roleActivationTime":  "0",
"policyDownloadedVersion": "33",
"policyDownloadTime":  "1700520586168",
"policyActiveVersion": "32",
"policyActivationTime":"1700519906012",
"tagDownloadedVersion":"16",
"tagDownloadTime": "1700533103456",
"tagActiveVersion":"15",
"tagActivationTime":   "1700532263341",
"gdsDownloadedVersion":"127",
"gdsDownloadTime": "1700533223180",
"gdsActiveVersion":"126",
"gdsActivationTime":   "1700532383325"
}
- verified that all existing tests pass successfully


Thanks,

Madhan Neethiraj

[jira] [Updated] (RANGER-4538) Plugin status should track GDS info download details as well



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

Madhan Neethiraj updated RANGER-4538:
-
Attachment: RANGER-4538.patch

> Plugin status should track GDS info download details as well
> 
>
> Key: RANGER-4538
> URL: https://issues.apache.org/jira/browse/RANGER-4538
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: RANGER-4538.patch
>
>
> Ranger admin tracks each plugin's downloading of following details: policies, 
> tags, userstore, roles. This should be extended to track GDS info as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] (RANGER-4524) FIx TestRangerMetricsContainerSource class UT

2023-11-20 Thread Dhaval Shah (Jira)



[ https://issues.apache.org/jira/browse/RANGER-4524 ]


Dhaval Shah deleted comment on RANGER-4524:
-

was (Author: dhavalshah9131):
Hi [~bpatel],

Please share the Review Request link.

Thanks

> FIx TestRangerMetricsContainerSource class UT
> -
>
> Key: RANGER-4524
> URL: https://issues.apache.org/jira/browse/RANGER-4524
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 
> 0001-RANGER-4524-Fix-TestRangerMetricsContainerSource-cla.patch
>
>
> Steps to reproduce:
> 1. clean .m2 repo and trigger the test-cases.
> {code:java}
> java.lang.NoClassDefFoundError: org/apache/log4j/Level at 
> org.apache.ranger.metrics.source.TestRangerMetricsContainerSource.init(TestRangerMetricsContainerSource.java:46)
>  Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Level at 
> org.apache.ranger.metrics.source.TestRangerMetricsContainerSource.init(TestRangerMetricsContainerSource.java:46){code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74701: RANGER-4493: Keep the UI behaviour for tag based and resource based services filtering for zone without any service

2023-11-20 Thread Brijesh Bhalala

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74701/
---

(Updated Nov. 21, 2023, 6:11 a.m.)

Review request for ranger, Dhaval Rajpara, Dineshkumar Yadav, Madhan Neethiraj,
Mehul Parikh, Mugdha Varadkar, Nikunj Pansuriya, and Nitin Galave.

Bugs: RANGER-4493
https://issues.apache.org/jira/browse/RANGER-4493

Repository: ranger

Description
---

In Ranger admin, security zones can be now created without any
services/resources.
If a security zone is created without any service, and on the service manager
page,
if the resource based services are filtered based on the zone without any
service,
then the UI displays an image with the text "No Services".
But if the same service filtering is done for tag based services, then the UI
shows a service element for tag.
It will be better if the UI behaviour is consistent for both resource and tag
based service filtering

In the current review request, I have improvise the code with following fixes :

1)Fix for the No service page in tag based.
2)Fix for the deleting the zone service while filtering zone.
3)Fix for import and export button click when there are no service while
filtering zone.

Diffs
-

security-admin/src/main/webapp/react-webapp/src/views/Home.jsx 67f71ec79

security-admin/src/main/webapp/react-webapp/src/views/ServiceManager/ServiceDefinitions.jsx
8c222d080

security-admin/src/main/webapp/react-webapp/src/views/ServiceManager/ServiceForm.jsx
47763fb9d
security-admin/src/main/webapp/react-webapp/src/views/SideBar/TopNavBar.jsx
d4dbc57d1

Diff: https://reviews.apache.org/r/74701/diff/3/

Testing (updated)
---

Tested changes on a cluster setup with Ranger Admin build with React JS code
base.
Verified the "Resource Based Policies" & "Tag Based Policies" Module.
Verified the policy listing page.

Thanks,

Brijesh Bhalala

Review Request 74747: RANGER-4532: Optimize policy listing loader after session timeout and Audit Admin session ID modal loader

2023-11-20 Thread Brijesh Bhalala


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74747/
---

Review request for ranger, Dhaval Rajpara and Mugdha Varadkar.


Bugs: RANGER-4532
https://issues.apache.org/jira/browse/RANGER-4532


Repository: ranger


Description
---

Optimize policy listing loader after session timeout and Audit Admin session ID 
modal loader.

Current behaviour :-
1) After session timeout, if we navigate to policy listing page then "Something 
went wrong page is seen" for fraction of seconds.
2) In Audit admin session Id modal, the loader is not in sync.

Improvising the loader logic in both above the scenarios.


Diffs
-

  
security-admin/src/main/webapp/react-webapp/src/views/AuditEvent/AdminModal.jsx 
be7736241 
  
security-admin/src/main/webapp/react-webapp/src/views/PolicyListing/PolicyListingTabView.jsx
 7c6b1c19b 


Diff: https://reviews.apache.org/r/74747/diff/1/


Testing
---

Testing is in progress


Thanks,

Brijesh Bhalala

[jira] [Updated] (RANGER-4532) Optimize policy listing loader after session timeout and Audit Admin session ID modal loader

2023-11-20 Thread Brijesh Bhalala (Jira)



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

Brijesh Bhalala updated RANGER-4532:

Attachment: 0001-RANGER-4532.patch

> Optimize policy listing  loader after session timeout  and  Audit Admin 
> session ID modal loader
> ---
>
> Key: RANGER-4532
> URL: https://issues.apache.org/jira/browse/RANGER-4532
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Brijesh Bhalala
>Assignee: Brijesh Bhalala
>Priority: Major
>  Labels: ranger-react
> Fix For: 3.0.0
>
> Attachments: 0001-RANGER-4532.patch
>
>
> Optimize policy listing  loader after session timeout and Audit Admin session 
> ID modal loader.
> Current behaviour  :-
> 1) After session timeout, if we navigate to policy listing page then 
> "Something went wrong page is seen" for fraction of seconds.
> 2) In Audit admin session Id modal, the loader is not in sync.
> Improvising the loader logic in both above the scenarios. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74746: RANGER-4538: updated plugin-status to record GDS info download details

2023-11-20 Thread Ramesh Mani


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74746/#review225984
---


Ship it!




Ship It!

- Ramesh Mani


On Nov. 21, 2023, 6:04 a.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74746/
> ---
> 
> (Updated Nov. 21, 2023, 6:04 a.m.)
> 
> 
> Review request for ranger, Anand Nadar, Ankita Sinha, Brijesh Bhalala, Dhaval 
> Rajpara, Abhay Kulkarni, Monika Kachhadiya, Ramesh Mani, Subhrat Chaudhary, 
> and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4538
> https://issues.apache.org/jira/browse/RANGER-4538
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> updated GDS info download API to record download details in plugin status
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/model/RangerPluginInfo.java
>  238a98242 
>   security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 8bbeba783 
>   security-admin/src/main/java/org/apache/ranger/rest/GdsREST.java 1c312e5e9 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerPluginInfoService.java
>  3a4746def 
> 
> 
> Diff: https://reviews.apache.org/r/74746/diff/1/
> 
> 
> Testing
> ---
> 
> - verified that GDS download details are stored in column x_plugin_info.info:
> {
> "pluginCapabilities":  "f",
> "adminCapabilities":   "f",
> "roleDownloadedVersion":   "1",
> "roleDownloadTime":"1700517922727",
> "roleActiveVersion":   "-1",
> "roleActivationTime":  "0",
> "policyDownloadedVersion": "33",
> "policyDownloadTime":  "1700520586168",
> "policyActiveVersion": "32",
> "policyActivationTime":"1700519906012",
> "tagDownloadedVersion":"16",
> "tagDownloadTime": "1700533103456",
> "tagActiveVersion":"15",
> "tagActivationTime":   "1700532263341",
> "gdsDownloadedVersion":"127",
> "gdsDownloadTime": "1700533223180",
> "gdsActiveVersion":"126",
> "gdsActivationTime":   "1700532383325"
> }
> - verified that all existing tests pass successfully
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 74745: RANGER-4282: updated audit logs to capture datasets and projects


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74745/
---

(Updated Nov. 21, 2023, 7:01 a.m.)


Review request for ranger, Anand Nadar, Ankita Sinha, Brijesh Bhalala, Dhaval 
Rajpara, Abhay Kulkarni, Mehul Parikh, Monika Kachhadiya, Mugdha Varadkar, 
Ramesh Mani, Subhrat Chaudhary, and Velmurugan Periasamy.


Changes
---

addressed review comments


Bugs: RANGER-4282
https://issues.apache.org/jira/browse/RANGER-4282


Repository: ranger


Description
---

- updated AuthzAuditEvent with 2 new fields: datasets, projects
- updated plugin to populate these 2 new fields in generated audit logs
- updated Solr and Elasticsearch schema to add new fields
- RANGER-4536 tracks audit UI updates to support the new fields


Diffs (updated)
-

  
agents-audit/src/main/java/org/apache/ranger/audit/destination/ElasticSearchAuditDestination.java
 1b17a934b 
  
agents-audit/src/main/java/org/apache/ranger/audit/destination/SolrAuditDestination.java
 f2e96bf9b 
  agents-audit/src/main/java/org/apache/ranger/audit/model/AuthzAuditEvent.java 
e20d1a786 
  
agents-audit/src/main/java/org/apache/ranger/audit/provider/solr/SolrAuditProvider.java
 9cda3f8f3 
  
agents-common/src/main/java/org/apache/ranger/plugin/audit/RangerDefaultAuditHandler.java
 c99465d7a 
  dev-support/ranger-docker/config/solr-ranger_audits/managed-schema c33f6de06 
  
security-admin/contrib/elasticsearch_for_audit_setup/conf/ranger_es_schema.json 
801667bce 
  security-admin/contrib/solr_for_audit_setup/conf/managed-schema c33f6de06 
  
security-admin/src/main/java/org/apache/ranger/amazon/cloudwatch/CloudWatchAccessAuditsService.java
 0b36f6e90 
  
security-admin/src/main/java/org/apache/ranger/elasticsearch/ElasticSearchAccessAuditsService.java
 4c9b049a0 
  
security-admin/src/main/java/org/apache/ranger/solr/SolrAccessAuditsService.java
 bb279349a 
  security-admin/src/main/java/org/apache/ranger/view/VXAccessAudit.java 
cce18fafb 


Diff: https://reviews.apache.org/r/74745/diff/2/

Changes: https://reviews.apache.org/r/74745/diff/1-2/


Testing
---

- verified audit logs written to Solr include datasets and projects associated 
with the resource
- verified audit logs retrieved via REST API calls include datasets and projects


Thanks,

Madhan Neethiraj

[jira] [Created] (RANGER-4539) Plugin status UI should render GDS download details