[jira] [Assigned] (RANGER-4654) [Ranger React UI] Handle Dataset and Datashare creation errors gracefully
[ https://issues.apache.org/jira/browse/RANGER-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek reassigned RANGER-4654: Assignee: Abhishek > [Ranger React UI] Handle Dataset and Datashare creation errors gracefully > - > > Key: RANGER-4654 > URL: https://issues.apache.org/jira/browse/RANGER-4654 > Project: Ranger > Issue Type: Sub-task > Components: admin >Reporter: Abhishek >Assignee: Abhishek >Priority: Major > Labels: ranger-react > > Whenever a datashare or a dataset is being created/updated with a name which > is already present, > then the UI shows "Data not found" message and shows options to return to > home page. > The error has to be handled gracefully. > Ideally, in such scenarios, the user should be able to modify the dataset / > datashare creation form by changing the name and submit the same form with > other existing details (This is the behavior with policy / service > creation/update form). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Review Request 74710: RANGER-4487: HSTS header missing from unsecured API in Ranger Admin
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74710/ --- (Updated Jan. 15, 2024, 9:56 a.m.) Review request for ranger, Dineshkumar Yadav, Kishor Gollapalliwar, Abhay Kulkarni, Madhan Neethiraj, Mehul Parikh, Pradeep Agrawal, Sailaja Polavarapu, and Velmurugan Periasamy. Bugs: RANGER-4487 https://issues.apache.org/jira/browse/RANGER-4487 Repository: ranger Description --- Currently for unsecured APIs, HSTS header are missing. Diffs - security-admin/src/main/resources/conf.dist/security-applicationContext.xml 807791f28 Diff: https://reviews.apache.org/r/74710/diff/1/ Testing (updated) --- HSTS header are present for unsecures APIs Thanks, sanket shelar
Re: Review Request 74837: RANGER-4653: Add inline assertions for displayName length in service creation / update form
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74837/#review226138 --- Ship it! Ship It! - Mugdha Varadkar On Jan. 13, 2024, 5:06 p.m., Abhishek Patil wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74837/ > --- > > (Updated Jan. 13, 2024, 5:06 p.m.) > > > Review request for ranger, Brijesh Bhalala, Dhaval Rajpara, Madhan Neethiraj, > Mehul Parikh, Mugdha Varadkar, and Ramesh Mani. > > > Bugs: RANGER-4653 > https://issues.apache.org/jira/browse/RANGER-4653 > > > Repository: ranger > > > Description > --- > > In the service create / update form, an inline assertion has to be added for > displayName validation (length and preventing use of special characters). > > > Diffs > - > > > security-admin/src/main/webapp/react-webapp/src/views/ServiceManager/ServiceForm.jsx > abb98954f > > > Diff: https://reviews.apache.org/r/74837/diff/1/ > > > Testing > --- > > Applied the patch on a cluster and tested the following UI scenarios :- > 1. Creation of a service with empty displayName, creation succeeded (expected > as displayName is not a mandatory field). > 2. Creation of a service with displayName that adheres to the valid regex (no > invalid special characters and length less than 256 characters), service > creation succeeded. > 3. Creation of a service with displayName with invalid special characters, > form submission failed (as expected). > 4. Creation of a service with displayName length greater than 256 characters, > form submission failed (as expected). > 5. Edit a service by modifying the displayName with valid name, edit > succeeded. > 6. Edit a service by modifying the displayName with invalid special > characters, form submission failed (as expected). > 7. Edit a service by modifying the displayName with length greater than 256 > characters, form submission failed (as expected). > > > Thanks, > > Abhishek Patil > >
Re: Review Request 74837: RANGER-4653: Add inline assertions for displayName length in service creation / update form
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74837/#review226139 --- Ship it! Ship It! - Brijesh Bhalala On Jan. 13, 2024, 5:06 p.m., Abhishek Patil wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74837/ > --- > > (Updated Jan. 13, 2024, 5:06 p.m.) > > > Review request for ranger, Brijesh Bhalala, Dhaval Rajpara, Madhan Neethiraj, > Mehul Parikh, Mugdha Varadkar, and Ramesh Mani. > > > Bugs: RANGER-4653 > https://issues.apache.org/jira/browse/RANGER-4653 > > > Repository: ranger > > > Description > --- > > In the service create / update form, an inline assertion has to be added for > displayName validation (length and preventing use of special characters). > > > Diffs > - > > > security-admin/src/main/webapp/react-webapp/src/views/ServiceManager/ServiceForm.jsx > abb98954f > > > Diff: https://reviews.apache.org/r/74837/diff/1/ > > > Testing > --- > > Applied the patch on a cluster and tested the following UI scenarios :- > 1. Creation of a service with empty displayName, creation succeeded (expected > as displayName is not a mandatory field). > 2. Creation of a service with displayName that adheres to the valid regex (no > invalid special characters and length less than 256 characters), service > creation succeeded. > 3. Creation of a service with displayName with invalid special characters, > form submission failed (as expected). > 4. Creation of a service with displayName length greater than 256 characters, > form submission failed (as expected). > 5. Edit a service by modifying the displayName with valid name, edit > succeeded. > 6. Edit a service by modifying the displayName with invalid special > characters, form submission failed (as expected). > 7. Edit a service by modifying the displayName with length greater than 256 > characters, form submission failed (as expected). > > > Thanks, > > Abhishek Patil > >
Re: [PR] RANGER-4640: Trino ranger plugin for 433 snapshot [ranger]
lozbrown commented on PR #291: URL: https://github.com/apache/ranger/pull/291#issuecomment-1892168147 is this likely to get reviewed/merged soon? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@ranger.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (RANGER-4655) Execute and read permissions granted to a user in different HDFS policies does not take effect.
Abhay Kulkarni created RANGER-4655: -- Summary: Execute and read permissions granted to a user in different HDFS policies does not take effect. Key: RANGER-4655 URL: https://issues.apache.org/jira/browse/RANGER-4655 Project: Ranger Issue Type: Bug Components: Ranger Reporter: Abhay Kulkarni Assignee: Abhay Kulkarni This bug is shown up when multiple accesses are requested using one access-request and all of the requested accesses need to be granted in order the access-request to be allowed. Test Case: Policy 1: Granted the "public" group "execute" permission to "/" HDFS policy recursively. Policy 2: Granted only the "read" permission to user for "/hdp" Doing a list on "/hdp" fails with permission denied for access READ_EXECUTE. However, the same works when "execute" permission is granted in Policy 2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4655) Execute and read permissions granted to a user in different HDFS policies does not take effect.
[ https://issues.apache.org/jira/browse/RANGER-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhay Kulkarni updated RANGER-4655: --- Description: This bug is shown up when multiple accesses are requested using one access-request and all of the requested accesses need to be granted in order the access-request to be allowed. This appears to be regression introduced by RANGER-3999 Test Case: Policy 1: Granted the "public" group "execute" permission to "/" HDFS policy recursively. Policy 2: Granted only the "read" permission to user for "/hdp" Doing a list on "/hdp" fails with permission denied for access READ_EXECUTE. However, the same works when "execute" permission is granted in Policy 2. was: This bug is shown up when multiple accesses are requested using one access-request and all of the requested accesses need to be granted in order the access-request to be allowed. Test Case: Policy 1: Granted the "public" group "execute" permission to "/" HDFS policy recursively. Policy 2: Granted only the "read" permission to user for "/hdp" Doing a list on "/hdp" fails with permission denied for access READ_EXECUTE. However, the same works when "execute" permission is granted in Policy 2. > Execute and read permissions granted to a user in different HDFS policies > does not take effect. > > > Key: RANGER-4655 > URL: https://issues.apache.org/jira/browse/RANGER-4655 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > > This bug is shown up when multiple accesses are requested using one > access-request and all of the requested accesses need to be granted in order > the access-request to be allowed. > > This appears to be regression introduced by RANGER-3999 > Test Case: > Policy 1: Granted the "public" group "execute" permission to "/" HDFS policy > recursively. > Policy 2: Granted only the "read" permission to user for "/hdp" > Doing a list on "/hdp" fails with permission denied for access READ_EXECUTE. > However, the same works when "execute" permission is granted in Policy 2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Review Request 74833: RANGER-4655: Execute and read permissions granted to a user in different HDFS policies does not take effect.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74833/ --- (Updated Jan. 16, 2024, 1:15 a.m.) Review request for ranger, Dineshkumar Yadav, madhan, Madhan Neethiraj, Pradeep Agrawal, Ramesh Mani, and Velmurugan Periasamy. Changes --- Updated the JIRA details Summary (updated) - RANGER-4655: Execute and read permissions granted to a user in different HDFS policies does not take effect. Bugs: RANGER-4655 https://issues.apache.org/jira/browse/RANGER-4655 Repository: ranger Description (updated) --- This bug is shown up when multiple accesses are requested using one access-request and all of the requested accesses need to be granted in order the access-request to be allowed. This appears to be regression introduced by RANGER-3999 Test Case: Policy 1: Granted the "public" group "execute" permission to "/" HDFS policy recursively. Policy 2: Granted only the "read" permission to user for "/hdp" Doing a list on "/hdp" fails with permission denied for access READ_EXECUTE. However, the same works when "execute" permission is granted in Policy 2. Diffs (updated) - agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java 252482c8e agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java 7fe2a2eb3 agents-common/src/main/java/org/apache/ranger/plugin/util/RangerAccessRequestUtil.java 92a4fe02e agents-common/src/test/java/org/apache/ranger/plugin/policyengine/TestPolicyEngine.java 2afbfebd4 Diff: https://reviews.apache.org/r/74833/diff/4/ Changes: https://reviews.apache.org/r/74833/diff/3-4/ Testing --- Passes all unit tests. Added unit test for checking the patch. Thanks, Abhay Kulkarni
[jira] [Commented] (RANGER-4225) Possible Jackson serialization issue due to not comply with Java bean standards
[
https://issues.apache.org/jira/browse/RANGER-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807051#comment-17807051
]
Bhavik Patel commented on RANGER-4225:
--
Sure.
Thanks [~sercan.tekin].
> Possible Jackson serialization issue due to not comply with Java bean
> standards
> ---
>
> Key: RANGER-4225
> URL: https://issues.apache.org/jira/browse/RANGER-4225
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 2.4.0
>Reporter: Sercan Tekin
>Assignee: Sercan Tekin
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: RANGER-4225.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> +*PROBLEM:*+
> Transitive Jackson-2 dependencies are included into Ranger's classpath in my
> env and conflicted with Jackson-1 dependencies.
> Jackson-2 uses Javabean naming conventions to figure out the Json properties
> in a Java class, and some of the Ranger's model classes don't comply with the
> convention.
> For example, when the leading camelcase word is only one letter in length,
> then deserialized response is broken. The following is what I observed in
> Ranger v2.4.0;
> On Ranger UI side, this
> [code-block|https://github.com/apache/ranger/blob/ranger-1.2/security-admin/src/main/webapp/scripts/views/policies/PermissionList.js#L224-L229]
> attempts to read vXStrings key in map, but the corresponding response has
> vxstrings instead:
> {code:java}
> {
> "startIndex": 0,
> "pageSize": 200,
> "totalCount": 11,
> "resultSize": 11,
> "sortType": "asc",
> "sortBy": "id",
> "listSize": 11,
> "vxstrings": [< here! This has to be vXStrings
> {
> "value": "public",
> ... {code}
> And this difference causes below error while reading the property, therefore
> the corresponding dropdown has no values as excepted;
> {code:java}
> PermissionList.js?ver=build.version:226 Uncaught TypeError: Cannot read
> properties of undefined (reading 'map')
> at Object.results (PermissionList.js?ver=build.version:226:34)
> at Object.success (select2.js?ver=build.version:450:47)
> at u (jquery-3.3.1.min.js?ver=build.version:2:27457)
> at Object.fireWith [as resolveWith]
> (jquery-3.3.1.min.js?ver=build.version:2:28202)
> at k (jquery-3.3.1.min.js?ver=build.version:2:77651)
> at XMLHttpRequest.
> (jquery-3.3.1.min.js?ver=build.version:2:79907){code}
> +*REFERENCES:*+
> Please see this reference related to capital letters
> [http://futuretask.blogspot.com/2005/01/java-tip-6-dont-capitalize-first-two.html]
> "Don't capitalize first two letters of a bean property name. This is in our
> java standards. You should not create a java bean property name that begins
> with a capital letter in the 1st two places."
> Also you can see the same issue is reported here
> [https://stackoverflow.com/questions/30205006/why-does-jackson-2-not-recognize-the-first-capital-letter-if-the-leading-camel-c]
>
> +*SOLUTION:*+
> {{@JsonProperty}} annotation needs to be added for mapping the properties
> with their corresponding getter/setter methods. This will not effect Ranger's
> functionality directly, but it will provide consistency even if Jackson-2 is
> included into classpath.
> I have tested it locally after adding {{@JsonProperty}} and everything worked
> well.
> The PR is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (RANGER-4656) Filtering the resources in the search filter options on the policy listing page based on policy type.
Brijesh Bhalala created RANGER-4656: --- Summary: Filtering the resources in the search filter options on the policy listing page based on policy type. Key: RANGER-4656 URL: https://issues.apache.org/jira/browse/RANGER-4656 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Brijesh Bhalala Fix For: 3.0.0 Filtering the resources in the search filter options on the policy listing page based on policy type. *Current Behaviour* :- * All the resources are displayed in search filter options on policy listing page, * For masking and row level all resources are their in search filter option, their is no filteration of resources on the basis of policy type. The resources should be filter on the basis of policy type in search filter options in policy listing page. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4656) Filtering the resources in the search filter options on the policy listing page based on policy type.
[ https://issues.apache.org/jira/browse/RANGER-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brijesh Bhalala reassigned RANGER-4656: --- Assignee: Brijesh Bhalala > Filtering the resources in the search filter options on the policy listing > page based on policy type. > - > > Key: RANGER-4656 > URL: https://issues.apache.org/jira/browse/RANGER-4656 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Brijesh Bhalala >Assignee: Brijesh Bhalala >Priority: Major > Fix For: 3.0.0 > > > Filtering the resources in the search filter options on the policy listing > page based on policy type. > *Current Behaviour* :- > * All the resources are displayed in search filter options on policy listing > page, > * For masking and row level all resources are their in search filter option, > their is no filteration of resources on the basis of policy type. > The resources should be filter on the basis of policy type in search filter > options in policy listing page. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4656) Filtering the resources in the search filter options on the policy listing page based on policy type.
[ https://issues.apache.org/jira/browse/RANGER-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brijesh Bhalala updated RANGER-4656: Description: Filtering the resources in the search filter options on the policy listing page based on policy type. *Current Behaviour* :- * All the resources are displayed in search filter options on policy listing page, * For masking and row level all resources are there in search filter option, there is no filteration of resources on the basis of policy type. The resources should be filter on the basis of policy type in search filter options in policy listing page. was: Filtering the resources in the search filter options on the policy listing page based on policy type. *Current Behaviour* :- * All the resources are displayed in search filter options on policy listing page, * For masking and row level all resources are their in search filter option, their is no filteration of resources on the basis of policy type. The resources should be filter on the basis of policy type in search filter options in policy listing page. > Filtering the resources in the search filter options on the policy listing > page based on policy type. > - > > Key: RANGER-4656 > URL: https://issues.apache.org/jira/browse/RANGER-4656 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Brijesh Bhalala >Assignee: Brijesh Bhalala >Priority: Major > Fix For: 3.0.0 > > > Filtering the resources in the search filter options on the policy listing > page based on policy type. > *Current Behaviour* :- > * All the resources are displayed in search filter options on policy listing > page, > * For masking and row level all resources are there in search filter option, > there is no filteration of resources on the basis of policy type. > The resources should be filter on the basis of policy type in search filter > options in policy listing page. -- This message was sent by Atlassian Jira (v8.20.10#820010)
