[jira] [Updated] (RANGER-4187) Not able to search using multiple user filter in access audit tab
[ https://issues.apache.org/jira/browse/RANGER-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mugdha Varadkar updated RANGER-4187: Summary: Not able to search using multiple user filter in access audit tab (was: Not able to search using muliple user filter in access audit tab) > Not able to search using multiple user filter in access audit tab > - > > Key: RANGER-4187 > URL: https://issues.apache.org/jira/browse/RANGER-4187 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Harshal Chavan >Assignee: Mugdha Varadkar >Priority: Major > Labels: ranger-react > > Steps > 1. Go to access audit tab > 2. Search with one user > 3. Try selecting user filter again > Note - we dont see user filter in 3 step -- 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
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74701/#review225952 --- Ship it! Ship It! - Mugdha Varadkar On Nov. 6, 2023, 12:56 p.m., Brijesh Bhalala wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74701/ > --- > > (Updated Nov. 6, 2023, 12:56 p.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 3dee1d086 > > security-admin/src/main/webapp/react-webapp/src/views/ServiceManager/ServiceDefinitions.jsx > 0b2f46bec > > security-admin/src/main/webapp/react-webapp/src/views/ServiceManager/ServiceForm.jsx > 2df0c4d63 > security-admin/src/main/webapp/react-webapp/src/views/SideBar/TopNavBar.jsx > d4dbc57d1 > > > Diff: https://reviews.apache.org/r/74701/diff/2/ > > > Testing > --- > > Testing is in progress > > > Thanks, > > Brijesh Bhalala > >
Review Request 74726: RANGER-4269: gds policy engine implementation of getResourceACLs() API
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74726/ --- Review request for ranger, Anand Nadar, Ankita Sinha, Abhay Kulkarni, Mehul Parikh, Monika Kachhadiya, Pradeep Agrawal, Prashant Satam, Ramesh Mani, Subhrat Chaudhary, and Velmurugan Periasamy. Bugs: RANGER-4269 https://issues.apache.org/jira/browse/RANGER-4269 Repository: ranger Description --- updated getResourceACLs() API to gather permissions granted via dataset and project policies Diffs - agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java e268fff38 agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerResourceACLs.java f8554d574 agents-common/src/main/java/org/apache/ranger/plugin/policyengine/gds/GdsDataShareEvaluator.java 83ab59630 agents-common/src/main/java/org/apache/ranger/plugin/policyengine/gds/GdsDatasetEvaluator.java 61047134b agents-common/src/main/java/org/apache/ranger/plugin/policyengine/gds/GdsDipEvaluator.java 2198eadf1 agents-common/src/main/java/org/apache/ranger/plugin/policyengine/gds/GdsDshidEvaluator.java 97bb06b2e agents-common/src/main/java/org/apache/ranger/plugin/policyengine/gds/GdsPolicyEngine.java 809bbfa96 agents-common/src/main/java/org/apache/ranger/plugin/policyengine/gds/GdsProjectEvaluator.java 446f2a90a agents-common/src/main/java/org/apache/ranger/plugin/policyengine/gds/GdsSharedResourceEvaluator.java 33a9e44fa agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerAbstractPolicyEvaluator.java b60fc9fb1 agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerPolicyEvaluator.java 0a14b387a agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java 71478f4bb agents-common/src/test/java/org/apache/ranger/plugin/policyengine/gds/TestGdsPolicyEngine.java 83bfc99f5 agents-common/src/test/resources/policyengine/gds/test_gds_policy_engine_hive.json 010baed5c Diff: https://reviews.apache.org/r/74726/diff/1/ Testing --- - added test cases to cover GDS policy engine implementation of getResourceACLs() - verified that all existing test cases pass successfully Thanks, Madhan Neethiraj
Re: Review Request 74721: RANGER-4515: Enhance perf-tracer to get CPU time when possible
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74721/#review225951 --- Ship it! Ship It! - Ramesh Mani On Nov. 7, 2023, 9:23 p.m., Abhay Kulkarni wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74721/ > --- > > (Updated Nov. 7, 2023, 9:23 p.m.) > > > Review request for ranger, madhan, Madhan Neethiraj, Mahesh Bandal, Ramesh > Mani, Sailaja Polavarapu, and Velmurugan Periasamy. > > > Bugs: RANGER-4515 > https://issues.apache.org/jira/browse/RANGER-4515 > > > Repository: ranger > > > Description > --- > > Some JVM versions provide the precision of nanoseconds for CPU time as well > as user time. Use nanosecond precision whenever available. > > > Diffs > - > > > agents-common/src/main/java/org/apache/ranger/plugin/util/PerfDataRecorder.java > 7e2c46fde > > agents-common/src/main/java/org/apache/ranger/plugin/util/RangerPerfCollectorTracer.java > 6e95a56ff > > agents-common/src/main/java/org/apache/ranger/plugin/util/RangerPerfTracer.java > 3c985c62c > > agents-common/src/main/java/org/apache/ranger/plugin/util/RangerPerfTracerFactory.java > 1a4e86dce > > > Diff: https://reviews.apache.org/r/74721/diff/2/ > > > Testing > --- > > Built ranger and ran all unit tests successfully. > > > Thanks, > > Abhay Kulkarni > >
Re: Review Request 74722: RANGER-4516: moved getResourceACLs() implementation from RangerPolicyEngine to RangerPolicyEvaluator
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74722/#review225950 --- Ship it! Ship It! - Ramesh Mani On Nov. 8, 2023, 1:06 a.m., Madhan Neethiraj wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74722/ > --- > > (Updated Nov. 8, 2023, 1:06 a.m.) > > > Review request for ranger, Ankita Sinha, Don Bosco Durai, Kishor > Gollapalliwar, Abhay Kulkarni, Mehul Parikh, Monika Kachhadiya, Pradeep > Agrawal, Ramesh Mani, Selvamohan Neethiraj, and Subhrat Chaudhary. > > > Bugs: RANGER-4516 > https://issues.apache.org/jira/browse/RANGER-4516 > > > Repository: ranger > > > Description > --- > > updated getResourceACLs() implementation to move evaluator specific code from > RangerPolicyEngine to RangerPolicyEvaluator > > > Diffs > - > > > agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java > 12f8a1705 > > agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerAbstractPolicyEvaluator.java > 5650b9ea8 > > agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerPolicyEvaluator.java > 0d4886c57 > > > Diff: https://reviews.apache.org/r/74722/diff/1/ > > > Testing > --- > > - verified that all existing unit tests pass successfully > > > Thanks, > > Madhan Neethiraj > >
[jira] [Updated] (RANGER-4516) move getResourceACLs() implementation from RangerPolicyEngineImpl to RangerPolicyEvaluator
[ https://issues.apache.org/jira/browse/RANGER-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Madhan Neethiraj updated RANGER-4516: - Attachment: RANGER-4516.patch > move getResourceACLs() implementation from RangerPolicyEngineImpl to > RangerPolicyEvaluator > -- > > Key: RANGER-4516 > URL: https://issues.apache.org/jira/browse/RANGER-4516 > Project: Ranger > Issue Type: Improvement > Components: plugins >Reporter: Madhan Neethiraj >Assignee: Madhan Neethiraj >Priority: Major > Fix For: 3.0.0 > > Attachments: RANGER-4516.patch > > > Implementation of getResourceACLs() largely depends on RangerPolicyEvaluator. > However, current implementation has most of the code in > RangerPolicyEngineImpl. Moving this to RangerPolicyEvaluator will help reused > of this code, for example in GDS policy evaluation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Review Request 74722: RANGER-4516: moved getResourceACLs() implementation from RangerPolicyEngine to RangerPolicyEvaluator
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74722/#review225948 --- Ship it! Ship It! - Selvamohan Neethiraj On Nov. 7, 2023, 8:06 p.m., Madhan Neethiraj wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74722/ > --- > > (Updated Nov. 7, 2023, 8:06 p.m.) > > > Review request for ranger, Ankita Sinha, Don Bosco Durai, Kishor > Gollapalliwar, Abhay Kulkarni, Mehul Parikh, Monika Kachhadiya, Pradeep > Agrawal, Ramesh Mani, Selvamohan Neethiraj, and Subhrat Chaudhary. > > > Bugs: RANGER-4516 > https://issues.apache.org/jira/browse/RANGER-4516 > > > Repository: ranger > > > Description > --- > > updated getResourceACLs() implementation to move evaluator specific code from > RangerPolicyEngine to RangerPolicyEvaluator > > > Diffs > - > > > agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java > 12f8a1705 > > agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerAbstractPolicyEvaluator.java > 5650b9ea8 > > agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerPolicyEvaluator.java > 0d4886c57 > > > Diff: https://reviews.apache.org/r/74722/diff/1/ > > > Testing > --- > > - verified that all exists unit tests pass successfully > > > Thanks, > > Madhan Neethiraj > >
Re: Review Request 74725: RANGER-4517: Sort param sortType is not considered if sortBy is not passed
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74725/#review225947 --- Ship it! Ship It! - Madhan Neethiraj On Nov. 8, 2023, 4:53 p.m., Subhrat Chaudhary wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74725/ > --- > > (Updated Nov. 8, 2023, 4:53 p.m.) > > > Review request for ranger, Anand Nadar, Ankita Sinha, Madhan Neethiraj, > Monika Kachhadiya, Prashant Satam, and Siddhesh Phatak. > > > Bugs: RANGER-4517 > https://issues.apache.org/jira/browse/RANGER-4517 > > > Repository: ranger > > > Description > --- > > The sort param sortType is not considered if sortBy is not passed in the > query-param. Please consider following case: > The GET API /service/gds/dataset has default sortType=asc and > sortBy=datasetId. If only sortType=desc is passed in query-param, sorting is > done in asc order and same is updated in response sortType=asc. > > > Diffs > - > > security-admin/src/main/java/org/apache/ranger/common/RangerConstants.java > f00ea05ca > security-admin/src/main/java/org/apache/ranger/common/RangerSearchUtil.java > ecb48e251 > > > Diff: https://reviews.apache.org/r/74725/diff/1/ > > > Testing > --- > > Validate sortBy and sortType params are working as expected. Use cases > validated: > 1. sortBy=datasetName, sortType=asc > 2. sortBy=datasetName, sortType=not passed (asc considered) > 3. sortBy=datasetName, sortType=desc > 4. sortBy=datasetId, sortType=asc > 5. sortBy=datasetId, sortType=not passed (asc considered) > 6. sortBy=datasetId, sortType=desc > 7. sortBy=createTime, sortType=asc > 8. sortBy=createTime, sortType=desc > 9. sortBy=createTime, sortType=not passed (asc considered) > > > Thanks, > > Subhrat Chaudhary > >
Review Request 74725: RANGER-4517: Sort param sortType is not considered if sortBy is not passed
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74725/ --- Review request for ranger, Anand Nadar, Ankita Sinha, Madhan Neethiraj, Monika Kachhadiya, Prashant Satam, and Siddhesh Phatak. Bugs: RANGER-4517 https://issues.apache.org/jira/browse/RANGER-4517 Repository: ranger Description --- The sort param sortType is not considered if sortBy is not passed in the query-param. Please consider following case: The GET API /service/gds/dataset has default sortType=asc and sortBy=datasetId. If only sortType=desc is passed in query-param, sorting is done in asc order and same is updated in response sortType=asc. Diffs - security-admin/src/main/java/org/apache/ranger/common/RangerConstants.java f00ea05ca security-admin/src/main/java/org/apache/ranger/common/RangerSearchUtil.java ecb48e251 Diff: https://reviews.apache.org/r/74725/diff/1/ Testing --- Validate sortBy and sortType params are working as expected. Use cases validated: 1. sortBy=datasetName, sortType=asc 2. sortBy=datasetName, sortType=not passed (asc considered) 3. sortBy=datasetName, sortType=desc 4. sortBy=datasetId, sortType=asc 5. sortBy=datasetId, sortType=not passed (asc considered) 6. sortBy=datasetId, sortType=desc 7. sortBy=createTime, sortType=asc 8. sortBy=createTime, sortType=desc 9. sortBy=createTime, sortType=not passed (asc considered) Thanks, Subhrat Chaudhary
[jira] [Assigned] (RANGER-4517) Sort param sortType not considered if sortBy not passed
[
https://issues.apache.org/jira/browse/RANGER-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Subhrat Chaudhary reassigned RANGER-4517:
-
Assignee: Subhrat Chaudhary
> Sort param sortType not considered if sortBy not passed
> ---
>
> Key: RANGER-4517
> URL: https://issues.apache.org/jira/browse/RANGER-4517
> Project: Ranger
> Issue Type: Sub-task
> Components: admin
>Reporter: Subhrat Chaudhary
>Assignee: Subhrat Chaudhary
>Priority: Major
>
> The sort param sortType is not considered if sortBy is not passed in the
> query-param. Please consider following case:
> * The GET API /service/gds/dataset has default sortType=asc and
> sortBy=datasetId.
> * Please find the query-param input and actual responses received:
>
> ||Request - sortBy||Request - sortType||Response - sortBy||Response -
> sortType||
> |Not passed|Not passed|datasetId|asc|
> |datasetName|Not passed|datasetName|asc|
> |datasetName|desc|datasetName|desc|
> |{color:#FF}Not
> passed{color}|{color:#FF}desc{color}|{color:#FF}datasetId{color}|{color:#FF}asc{color}|
> |datasetId|desc|datasetId|desc|
> As noticed above if the sortBy is not passed in the request query-param
> sortType param is not considered.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (RANGER-4517) Sort param sortType not considered if sortBy not passed
Subhrat Chaudhary created RANGER-4517:
-
Summary: Sort param sortType not considered if sortBy not passed
Key: RANGER-4517
URL: https://issues.apache.org/jira/browse/RANGER-4517
Project: Ranger
Issue Type: Sub-task
Components: admin
Reporter: Subhrat Chaudhary
The sort param sortType is not considered if sortBy is not passed in the
query-param. Please consider following case:
* The GET API /service/gds/dataset has default sortType=asc and
sortBy=datasetId.
* Please find the query-param input and actual responses received:
||Request - sortBy||Request - sortType||Response - sortBy||Response - sortType||
|Not passed|Not passed|datasetId|asc|
|datasetName|Not passed|datasetName|asc|
|datasetName|desc|datasetName|desc|
|{color:#FF}Not
passed{color}|{color:#FF}desc{color}|{color:#FF}datasetId{color}|{color:#FF}asc{color}|
|datasetId|desc|datasetId|desc|
As noticed above if the sortBy is not passed in the request query-param
sortType param is not considered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-4509) There is a space missing in the log
[
https://issues.apache.org/jira/browse/RANGER-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daqian Liao reassigned RANGER-4509:
---
Assignee: Daqian Liao
> There is a space missing in the log
> ---
>
> Key: RANGER-4509
> URL: https://issues.apache.org/jira/browse/RANGER-4509
> Project: Ranger
> Issue Type: Improvement
> Components: usersync
>Affects Versions: 2.4.0
>Reporter: Daqian Liao
>Assignee: Daqian Liao
>Priority: Trivial
> Attachments: space.patch
>
>
>
> before：
> LOG.info("timeStampVal = " + timeStampVal + "and currentDeltaSyncTime = " +
> currentDeltaSyncTime);
>
> after：
> LOG.info("timeStampVal = " + timeStampVal + " and currentDeltaSyncTime = " +
> currentDeltaSyncTime);
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-4501) creating a service will throw NPE when using service.check.user parameter
[
https://issues.apache.org/jira/browse/RANGER-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daqian Liao reassigned RANGER-4501:
---
Assignee: Daqian Liao
> creating a service will throw NPE when using service.check.user parameter
> -
>
> Key: RANGER-4501
> URL: https://issues.apache.org/jira/browse/RANGER-4501
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 2.4.0
>Reporter: Daqian Liao
>Assignee: Daqian Liao
>Priority: Major
> Attachments: NEP.png, create_user.patch
>
>
> !NEP.png|width=899,height=487!
>
> {code:java}
> //代码占位符
> 2023-10-27 12:02:45,799 [http-nio-6080-exec-13] ERROR [ServiceREST.java:775]
> createService(RangerService={id={null} guid={null} isEnabled={true}
> createdBy={null} updatedBy={null} createTime={null} updateTime={null}
> version={1} name={trino-service-check-user}
> displayName={trino-service-check-user} type={trino}
> description={trino-service-check-user} tagService={} configs={password={}
> service.check.user={ii,oo} ranger.plugin.audit.filters={}
> jdbc.driverClassName={io.trino.jdbc.TrinoDriver}
> jdbc.url={jdbc:presto://localhost:9000} username={hadoop} }
> policyVersion={null} policyUpdateTime={null} tagVersion={1}
> tagUpdateTime={null} }) failed
> java.lang.NullPointerException: null
> at
> org.apache.ranger.biz.ServiceDBStore.populateDefaultPolicies(ServiceDBStore.java:3345)
> at
> org.apache.ranger.biz.ServiceDBStore.createDefaultPolicies(ServiceDBStore.java:3261)
> at
> org.apache.ranger.biz.ServiceDBStore.createService(ServiceDBStore.java:1576)
> at
> org.apache.ranger.rest.ServiceREST.createService(ServiceREST.java:771)
> at
> org.apache.ranger.rest.ServiceREST$$FastClassBySpringCGLIB$$92dab672.invoke()
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:783)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:753)
> at
> org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:61)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:753)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:753)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:698)
> at
> org.apache.ranger.rest.ServiceREST$$EnhancerBySpringCGLIB$$8c627be3.createService()
> at sun.reflect.GeneratedMethodAccessor844.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImp
[jira] [Updated] (RANGER-4513) Policy listing page experiences an reset to Access tab when attempting to filter the service and zone dropdown options.
[ https://issues.apache.org/jira/browse/RANGER-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brijesh Bhalala updated RANGER-4513: Summary: Policy listing page experiences an reset to Access tab when attempting to filter the service and zone dropdown options. (was: Policy listing page experiences an unexpected reset to Access tab when attempting to filter the service and zone dropdown options. ) > Policy listing page experiences an reset to Access tab when attempting to > filter the service and zone dropdown options. > - > > Key: RANGER-4513 > URL: https://issues.apache.org/jira/browse/RANGER-4513 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Brijesh Bhalala >Assignee: Brijesh Bhalala >Priority: Major > Labels: ranger-react > Fix For: 3.0.0 > > > The policy listing page experiences an unexpected reset when attempting to > filter the service and zone dropdown options. > *Steps to Reproduce:* > # Navigate to the "hive" policy listing page. > # Goto Masking tab > # Select the "Service" dropdown to filter policies based on a specific > service. > # Select the "Zone" dropdown to filter policies based on specific zone. > # Observe that the page resets to the default "Access" tab > *Expected Behavior:* > The page should retain the selected tab when filtering the service and zone > dropdown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-4318) Switching between keymanager and audits pages with idle time in between causes delays in loading page
[ https://issues.apache.org/jira/browse/RANGER-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhaval Rajpara resolved RANGER-4318. Resolution: Fixed > Switching between keymanager and audits pages with idle time in between > causes delays in loading page > - > > Key: RANGER-4318 > URL: https://issues.apache.org/jira/browse/RANGER-4318 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Dhaval Rajpara >Assignee: Dhaval Rajpara >Priority: Major > Labels: ranger-react > > Scenario: > Logged in to ranger admin UI as keyadmin user > Switch to UI with react and lefthand side tab changes > Click on keymanager. Wait for page to load. > Wait for few minutes. > Click on Audits page. Wait for page to load. > Observed that the switch between pages take less time if there is no idle > time in between. > With idle time it takes between 7-12 secs for page to load with just 1 or 2 > keys and very less no of audits -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4318) Switching between keymanager and audits pages with idle time in between causes delays in loading page
[ https://issues.apache.org/jira/browse/RANGER-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784010#comment-17784010 ] Dhaval Rajpara commented on RANGER-4318: This is is getting handled in [RANGER-4331|https://issues.apache.org/jira/browse/RANGER-4331] along with the regression. > Switching between keymanager and audits pages with idle time in between > causes delays in loading page > - > > Key: RANGER-4318 > URL: https://issues.apache.org/jira/browse/RANGER-4318 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Dhaval Rajpara >Assignee: Dhaval Rajpara >Priority: Major > Labels: ranger-react > > Scenario: > Logged in to ranger admin UI as keyadmin user > Switch to UI with react and lefthand side tab changes > Click on keymanager. Wait for page to load. > Wait for few minutes. > Click on Audits page. Wait for page to load. > Observed that the switch between pages take less time if there is no idle > time in between. > With idle time it takes between 7-12 secs for page to load with just 1 or 2 > keys and very less no of audits -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4360) Error page 'Go back' button not redirecting to the right page
[ https://issues.apache.org/jira/browse/RANGER-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mugdha Varadkar updated RANGER-4360: Labels: ranger-react (was: ) > Error page 'Go back' button not redirecting to the right page > -- > > Key: RANGER-4360 > URL: https://issues.apache.org/jira/browse/RANGER-4360 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Harshal Chavan >Assignee: Dhaval Rajpara >Priority: Major > Labels: ranger-react > Attachments: 0001-RANGER-4360.patch > > > On error page Go back button not work properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4512) [Ranger React UI] Unnecessary options are present in "Cluster" resource selection dropdown of cm_kafka_connect create policy form
[
https://issues.apache.org/jira/browse/RANGER-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mugdha Varadkar reassigned RANGER-4512:
---
Assignee: Dhaval Rajpara
> [Ranger React UI] Unnecessary options are present in "Cluster" resource
> selection dropdown of cm_kafka_connect create policy form
> -
>
> Key: RANGER-4512
> URL: https://issues.apache.org/jira/browse/RANGER-4512
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Kundan Kumar Jha
>Assignee: Dhaval Rajpara
>Priority: Major
> Labels: ranger-react
> Attachments: Screenshot 2023-10-25 at 1.02.28 PM.png
>
>
> *PROBLEM STATEMENT:*
> Values typed in "Cluster" resource type for "cm_kafka_connect" policy
> creation form also comes up as a selection option in the resulted dropdown
> although the only allowed value is "*".
> *STEPS TO REPRODUCE:*
> 1. Open ranger UI and click on cm_kafka_connect resource from resource policy
> section.
> 2. Select "Cluster" from resources and type "abcde" in the input box.
> 3. It will open a search dropdown.
> *CURRENT BEHAVIOUR:*
> The search dropdown contains two values "{*}" and "abcde". But if we select
> "abcde" it will show a error msg as "Only "{*}" value is allowed".
> *EXPECTED BEHAVIOUR:*
> Either the input box should be replaced by the only possible value "*". Or if
> another values also possible then allow them and add some proper hint msg.
> *IMPACT:*
> Ranger UI looks ambiguous.
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4481) Add a configuration item to support Ranger client not using authentication
[ https://issues.apache.org/jira/browse/RANGER-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xuze Yang updated RANGER-4481: -- Attachment: 0001-RANGER-4481-remove-the-matched-supported-s-entrySet-.patch > Add a configuration item to support Ranger client not using authentication > -- > > Key: RANGER-4481 > URL: https://issues.apache.org/jira/browse/RANGER-4481 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 2.1.0 >Reporter: Xuze Yang >Assignee: Xuze Yang >Priority: Major > Attachments: > 0001-RANGER-4481-remove-the-matched-supported-s-entrySet-.patch, feasible > solution code.png, first http response.png, openjdk problem code.png, second > http request.png > > > As described in RANGER-3602, ranger supports downloading policies and roles > through unauthenticated http requests even if kerberos is enabled on the > server. > But in terms of the current implementation of RangerAdminRESTClient, whether > to enable authenticated HTTP requests depends on the service in which it is > located. For example, if the Hadoop service has kerberos enabled, then the > RangerAdminRESTClient in the HDFS and Yarn plugins will also use > authenticated HTTP requests. > I think this is not reasonable enough. In this case (both the Ranger server > and Hadoop are enabled for kerberos), the RangerAdminRESTClient of the HDFS > and Yarn plugins should also be allowed to download policies and roles > through unauthenticated HTTP requests. > The reason why I proposed this improvement is due to a bug I encountered in > our production environment. I will introduce the bug I encountered later. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4481) Add a configuration item to support Ranger client not using authentication
[
https://issues.apache.org/jira/browse/RANGER-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783990#comment-17783990
]
Xuze Yang commented on RANGER-4481:
---
This problem can be reproduced everytime according to the following steps:
Environment: 2 ranger servers（called ranger0 and ranger1）, 1 kerberos
1. Restart the ranger client (to ensure that the ranger client has
interacted with only one ranger server)
2. Determine the range server that the range client reqeust to, assuming
it is range0
3. Make the kerberos unavailable
4. Make ranger0 unavailable
5. Make the kerberos available
A little explanation: In step 4, by making range0 unavailable, the ranger
client will switch to interacting with range1. After the first HTTP request
returns 401, the ranger client will request a ticket for ranger1 from kerberos.
However, due to kerberos's unavailable at this time, the ticket request failed.
And Because it's the first time for ranger client interact with ranger1,
NegotiateAuthentication#supported will put the entry: \{ranger1's hostname,
false}, and it will continue to return false in subsequent requests.
After applying the provided patch, the ranger client can pull policies after
kerberos returns to normal.
> Add a configuration item to support Ranger client not using authentication
> --
>
> Key: RANGER-4481
> URL: https://issues.apache.org/jira/browse/RANGER-4481
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Affects Versions: 2.1.0
>Reporter: Xuze Yang
>Assignee: Xuze Yang
>Priority: Major
> Attachments: feasible solution code.png, first http response.png,
> openjdk problem code.png, second http request.png
>
>
> As described in RANGER-3602, ranger supports downloading policies and roles
> through unauthenticated http requests even if kerberos is enabled on the
> server.
> But in terms of the current implementation of RangerAdminRESTClient, whether
> to enable authenticated HTTP requests depends on the service in which it is
> located. For example, if the Hadoop service has kerberos enabled, then the
> RangerAdminRESTClient in the HDFS and Yarn plugins will also use
> authenticated HTTP requests.
> I think this is not reasonable enough. In this case (both the Ranger server
> and Hadoop are enabled for kerberos), the RangerAdminRESTClient of the HDFS
> and Yarn plugins should also be allowed to download policies and roles
> through unauthenticated HTTP requests.
> The reason why I proposed this improvement is due to a bug I encountered in
> our production environment. I will introduce the bug I encountered later.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
