[jira] [Resolved] (TC-535) DS URL sig key apis needs to have tenancy check in place
[
https://issues.apache.org/jira/browse/TC-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher resolved TC-535.
---
Resolution: Fixed
> DS URL sig key apis needs to have tenancy check in place
>
>
> Key: TC-535
> URL: https://issues.apache.org/jira/browse/TC-535
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Nir Sopher
> Fix For: 2.1.0, 2.2.0
>
>
> Tenancy was introduced in 2.1, however, by default it is turned off via the
> use_tenancy parameter but when activated it is used to limit the scope of
> delivery services that a user can act on.
> The following APIs needs to check tenancy to ensure users cannot act on ds's
> that they don't have access to.
> post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/generate
> post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/copyFromXmlId/:copyFromXmlId
> get("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TC-550) TO API - fetch deliveryservices for a user should have tenancy hooked in
[ https://issues.apache.org/jira/browse/TC-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139010#comment-16139010 ] Nir Sopher commented on TC-550: --- What is the purpose of this endpoint? When writing the code I considered it as a "read" endpoint to the DS/User table, not as "give me the list of DSes another user can see". Nir > TO API - fetch deliveryservices for a user should have tenancy hooked in > > > Key: TC-550 > URL: https://issues.apache.org/jira/browse/TC-550 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell > > The following api route does not take into consideration the tenancy of the > specified user: > get( "/api/$version/users/:id/deliveryservices > it currently does the following: > 1. it checks the tenancy of the specified user vs. the tenancy of the current > user to ensure the current user can see the specified user <-- this is good > 2. it queries the deliveryservice_tmuser table to find the delivery services > associated to the tm_user and then if finally filters the results based on > the current user's tenancy <-- it should not query this table if use_tenancy > = 1 > if use_tenancy = 0, it should work the way it does now > if use_tenancy = 1, it should not query the deliveryservice_tmuser table but > instead query the deliveryservice table and filter the results against the > specified user's tenant AND the current user's tenant. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] incubator-trafficcontrol issue #831: [TC-535] url sig - tenancy checks
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/831 This test had no issues on my VM. It can be removed, but I do not understand what is the cause of the failure. Any additional inputs in the log from the failure? 10x, Nir --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #831: [TC-535] url sig - tenancy check...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/831#discussion_r134098841
--- Diff: traffic_ops/app/lib/API/DeliveryService/KeysUrlSig.pm ---
@@ -98,7 +118,7 @@ sub copy_url_sig_keys {
if ( defined($url_sig_key_values_json) ) { # verify we got keys copied
# Admins can always do this, otherwise verify the user
if ( $helper->is_valid_delivery_service($ds_id) ) {
- if ( $is_admin ||
$helper->is_delivery_service_assigned($ds_id) ) {
+ if ( $is_admin ||
$helper->is_delivery_service_assigned($ds_id) || $tenant_utils->use_tenancy()) {
--- End diff --
Same as before, covered by line 76
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #831: [TC-535] url sig - tenancy check...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/831#discussion_r134098817
--- Diff: traffic_ops/app/lib/API/DeliveryService/KeysUrlSig.pm ---
@@ -69,14 +86,17 @@ sub copy_url_sig_keys {
else {
return $self->alert("Delivery Service to copy from
'$copy_from_xml_id' does not exist.");
}
+ if (!$tenant_utils->is_ds_resource_accessible($tenants_data,
$copy_rs->tenant_id)) {
+ return $self->forbidden("Forbidden. Source delivery-service
tenant is not available to the user.");
+ }
my $copy_config_file =
$self->url_sig_config_file_name($copy_from_xml_id);
my $helper = new Utils::Helper( { mojo => $self } );
my $url_sig_key_values_json;
#verify we can copy keys out
if ( $helper->is_valid_delivery_service($copy_ds_id) ) {
- if ( $is_admin ||
$helper->is_delivery_service_assigned($copy_ds_id) ) {
+ if ( $is_admin ||
$helper->is_delivery_service_assigned($copy_ds_id) ||
$tenant_utils->use_tenancy()) {
--- End diff --
Correct, the "|| use_tenancy" in this line come only to disable the legacy
tests in case we use tenancy.
If the tenancy is on, we will not even get to this line (we will exit on
line 90)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #832: [TC-533] ssl_keys - tenancy chec...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/832 [TC-533] ssl_keys - tenancy checks Adding tenancy checks to the DS ssl_keys API. Still with limited testing You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol tc-533 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/832.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #832 commit f21c76a4aae8ce83e0f364701e87897ffa5c4249 Author: nir-sopher <n...@qwilt.com> Date: 2017-08-13T16:01:38Z ssl_keys - tenancy checks --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #831: [TC-535] url sig - tenancy check...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/831 [TC-535] url sig - tenancy checks You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol tc-535 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/831.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #831 commit ef783a34b16d6ee53b6520b49e9934a8f295cbb4 Author: nir-sopher <n...@qwilt.com> Date: 2017-08-13T15:25:37Z url sig - tenancy checks --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Comment Edited] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130943#comment-16130943 ] Nir Sopher edited comment on TC-384 at 8/17/17 6:16 PM: The "type" should added to the "profile" dictionary in the profile json. For example "type":"ATS_PROFILE". The below command should do the trick (for ATS_PROFILE): sed -i -- 's/}}/,"type":"ATS_PROFILE"}}/g' * [~dangogh] I agree it better appear in the RN. How do we do that. was (Author: nirsopher): The "type" should added to the "profile" dictionary in the profile json. For example "type":"ATS_PROFILE". The below command should do the trick (for ATS_PROFILE): sed -i -- 's/}}/,"type":"ATS_PROFILE"}}/g' * [~dangogh] I think it better appear in the RN. How do we do that. > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher >Assignee: Dan Kirkwood > Labels: profile_parameters > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130943#comment-16130943 ] Nir Sopher commented on TC-384: --- The "type" should added to the "profile" dictionary in the profile json. For example "type":"ATS_PROFILE". The below command should do the trick (for ATS_PROFILE): sed -i -- 's/}}/,"type":"ATS_PROFILE"}}/g' * [~dangogh] I think it better appear in the RN. How do we do that. > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher >Assignee: Dan Kirkwood > Labels: profile_parameters > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128655#comment-16128655 ] Nir Sopher commented on TC-384: --- Waiting for 2.2 will make it irrelevant. I think it can be dismissed. If someone needs to import a profile he should manually add the profile-type to the json > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0 > Reporter: Nir Sopher >Assignee: Dan Kirkwood > Labels: profile_parameters > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-384: -- Issue Type: Improvement (was: Bug) > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0 > Reporter: Nir Sopher >Assignee: Dan Kirkwood > Labels: profile_parameters > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-531) Traffic Monitor does not pull new cr-config when all servers in in "ONLINE" and not "REPORTED"
Nir Sopher created TC-531:
-
Summary: Traffic Monitor does not pull new cr-config when all
servers in in "ONLINE" and not "REPORTED"
Key: TC-531
URL: https://issues.apache.org/jira/browse/TC-531
Project: Traffic Control
Issue Type: Bug
Components: Traffic Monitor (golang)
Affects Versions: 2.1.0
Reporter: Nir Sopher
Priority: Minor
When all cache servers are forced to be ONLINE, TM seems not to pull the cfg,
with the below message in the log
"No REPORTED caches exist in Traffic Ops, nothing to poll."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-530) TRAFFIC_ROUTER default profile points to non existing coverage-zone DB endpoint
Nir Sopher created TC-530:
-
Summary: TRAFFIC_ROUTER default profile points to non existing
coverage-zone DB endpoint
Key: TC-530
URL: https://issues.apache.org/jira/browse/TC-530
Project: Traffic Control
Issue Type: Improvement
Components: Documentation
Affects Versions: 2.1.0
Reporter: Nir Sopher
Priority: Minor
The "coveragezone.polling.url" variable in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
is set to http://${toHostname}/cdn/CZF/current/czf-current.json
However, this path does not exists in my traffic ops.
However, the path "routing/coverage-zone.json" does exists
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-526) TM does not pull configuration where no DS/Server assignment exists
[
https://issues.apache.org/jira/browse/TC-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-526:
--
Description:
When DSes and Servers are already configured in traffic-ops, cr-config can be
generated.
However, TM (and therefore the TR) ignores the cr-config if there is no
DS/Server assignment ("MonitorConfigPoller: skipping this iteration, Session is
nil").
As the cr-config hold much more than this mapping, I would like to suggest the
configuration would not be ignored.
> TM does not pull configuration where no DS/Server assignment exists
> ---
>
> Key: TC-526
> URL: https://issues.apache.org/jira/browse/TC-526
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Monitor (golang)
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
> When DSes and Servers are already configured in traffic-ops, cr-config can be
> generated.
> However, TM (and therefore the TR) ignores the cr-config if there is no
> DS/Server assignment ("MonitorConfigPoller: skipping this iteration, Session
> is nil").
> As the cr-config hold much more than this mapping, I would like to suggest
> the configuration would not be ignored.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-527) Traffic_Router Default Profile - Uses unsupported pattern (${toHostname})
[
https://issues.apache.org/jira/browse/TC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-527:
--
Description:
Few variables in the TRAFFIC_ROUTER default profile published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
uses the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
I would suggest to add a "README" besides the default profile, with
instructions to replace this pattern manually (until TR supports it)
> Traffic_Router Default Profile - Uses unsupported pattern (${toHostname})
> -
>
> Key: TC-527
> URL: https://issues.apache.org/jira/browse/TC-527
> Project: Traffic Control
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 2.1.0
> Environment: Few variables in the TRAFFIC_ROUTER default profile
> published at
> http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
> uses the pattern ${toHostname}, however, at least till commit
> 3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace
> this pattern with the ops hostname.
> I would suggest to add a "README" besides the default profile, with
> instructions to replace this pattern manually (until TR supports it)
>Reporter: Nir Sopher
>Priority: Minor
>
> Few variables in the TRAFFIC_ROUTER default profile published at
> http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
> uses the pattern ${toHostname}, however, at least till commit
> 3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace
> this pattern with the ops hostname.
> I would suggest to add a "README" besides the default profile, with
> instructions to replace this pattern manually (until TR supports it)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-526) TM does not pull configuration where no DS/Server assignment exists
[
https://issues.apache.org/jira/browse/TC-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-526:
--
Environment: (was: When DSes and Servers are already configured in
traffic-ops, cr-config can be generated.
However, TM (and therefore the TR) ignores the cr-config if there is no
DS/Server assignment ("MonitorConfigPoller: skipping this iteration, Session is
nil").
As the cr-config hold much more than this mapping, I would like to suggest the
configuration would not be ignored.)
> TM does not pull configuration where no DS/Server assignment exists
> ---
>
> Key: TC-526
> URL: https://issues.apache.org/jira/browse/TC-526
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Monitor (golang)
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-528) Traffic Router - To support the ${toHostname} pattern when parsing the cr-config
[
https://issues.apache.org/jira/browse/TC-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-528:
--
Description:
Few variables in the TRAFFIC_ROUTER default profile published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
use the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
> Traffic Router - To support the ${toHostname} pattern when parsing the
> cr-config
>
>
> Key: TC-528
> URL: https://issues.apache.org/jira/browse/TC-528
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Router
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
> Few variables in the TRAFFIC_ROUTER default profile published at
> http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
> use the pattern ${toHostname}, however, at least till commit
> 3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace
> this pattern with the ops hostname.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-528) Traffic Router - To support the ${toHostname} pattern when parsing the cr-config
[
https://issues.apache.org/jira/browse/TC-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-528:
--
Environment: (was: Few variables in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
use the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
)
> Traffic Router - To support the ${toHostname} pattern when parsing the
> cr-config
>
>
> Key: TC-528
> URL: https://issues.apache.org/jira/browse/TC-528
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Router
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-529) TRAFFIC_ROUTER default profile points to non existing geolocation DB endpoint
[
https://issues.apache.org/jira/browse/TC-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-529:
--
Description:
The "geolocation.polling.url" variable in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
is set to http://${toHostname}/MaxMind/auto/GeoIP2-City.mmdb.gz.
However, this path does not exists in my traffic ops.
However, the path "routing/GeoLite2-City.mmdb.gz" does exists
was:
The "eolocation.polling.url" variable in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
is set to http://${toHostname}/MaxMind/auto/GeoIP2-City.mmdb.gz.
However, this path does not exists in my traffic ops.
However, the path "routing/GeoLite2-City.mmdb.gz" does exists
> TRAFFIC_ROUTER default profile points to non existing geolocation DB endpoint
> -
>
> Key: TC-529
> URL: https://issues.apache.org/jira/browse/TC-529
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Router
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
> The "geolocation.polling.url" variable in the TRAFFIC_ROUTER default profile
> published at
> http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
> is set to http://${toHostname}/MaxMind/auto/GeoIP2-City.mmdb.gz.
> However, this path does not exists in my traffic ops.
> However, the path "routing/GeoLite2-City.mmdb.gz" does exists
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-529) TRAFFIC_ROUTER default profile points to non existing geolocation DB endpoint
Nir Sopher created TC-529:
-
Summary: TRAFFIC_ROUTER default profile points to non existing
geolocation DB endpoint
Key: TC-529
URL: https://issues.apache.org/jira/browse/TC-529
Project: Traffic Control
Issue Type: Improvement
Components: Traffic Router
Affects Versions: 2.1.0
Reporter: Nir Sopher
Priority: Minor
The "eolocation.polling.url" variable in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
is set to http://${toHostname}/MaxMind/auto/GeoIP2-City.mmdb.gz.
However, this path does not exists in my traffic ops.
However, the path "routing/GeoLite2-City.mmdb.gz" does exists
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-528) Traffic Router - To support the ${toHostname} pattern when parsing the cr-config
Nir Sopher created TC-528:
-
Summary: Traffic Router - To support the ${toHostname} pattern
when parsing the cr-config
Key: TC-528
URL: https://issues.apache.org/jira/browse/TC-528
Project: Traffic Control
Issue Type: Improvement
Components: Traffic Router
Affects Versions: 2.1.0
Environment: Few variables in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
use the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
Reporter: Nir Sopher
Priority: Minor
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-527) Traffic_Router Default Profile - Uses unsupported pattern (${toHostname})
Nir Sopher created TC-527:
-
Summary: Traffic_Router Default Profile - Uses unsupported pattern
(${toHostname})
Key: TC-527
URL: https://issues.apache.org/jira/browse/TC-527
Project: Traffic Control
Issue Type: Improvement
Components: Documentation
Affects Versions: 2.1.0
Environment: Few variables in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
uses the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
I would suggest to add a "README" besides the default profile, with
instructions to replace this pattern manually (until TR supports it)
Reporter: Nir Sopher
Priority: Minor
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-525) Cannot snapshot CrConfig when no mid server exists
Nir Sopher created TC-525: - Summary: Cannot snapshot CrConfig when no mid server exists Key: TC-525 URL: https://issues.apache.org/jira/browse/TC-525 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher Traffic Control works well with no MID servers. The edge server can just work against the origin. However, if no "MID" server exists, snapshot cr-config fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-508) Import Profile may create parameters duplications
[ https://issues.apache.org/jira/browse/TC-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher closed TC-508. - Resolution: Invalid Jeremy is correct. I was probably confused due to the appearance of the same variable twice in the list (once per profile) > Import Profile may create parameters duplications > - > > Key: TC-508 > URL: https://issues.apache.org/jira/browse/TC-508 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0 > Reporter: Nir Sopher > > I had an ops server, loaded with the default profiles as published in the > web-site. > I tried to had an exported old ATS 5.3 profile as well. > It then created a situation where I have 2 parameters with the same "name, > file, value" set. > If for example I delete one of them, the other is deleted as well... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-501) TPv2 installation - better defaults are required
[ https://issues.apache.org/jira/browse/TC-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-501: -- Issue Type: Improvement (was: Bug) > TPv2 installation - better defaults are required > > > Key: TC-501 > URL: https://issues.apache.org/jira/browse/TC-501 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Affects Versions: 2.1.0 > Reporter: Nir Sopher > > After basic install of traffic-portal based on the documentation, traffic > portal failed to launch. this is due to relative pathes to the logs and > static files appear in the default configuration. > Note that the working directory of the server is "/" > First, the log path (./server/log) does not exists. A possible fix is to > change the dir to /opt/traffic_portal/server/log and create the log dir if > needed. > Second. the files static path should be set to "opt/traffic_portal/public" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-508) Import Profile may create parameters duplications
Nir Sopher created TC-508: - Summary: Import Profile may create parameters duplications Key: TC-508 URL: https://issues.apache.org/jira/browse/TC-508 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Affects Versions: 2.1.0 Reporter: Nir Sopher I had an ops server, loaded with the default profiles as published in the web-site. I tried to had an exported old ATS 5.3 profile as well. It then created a situation where I have 2 parameters with the same "name, file, value" set. If for example I delete one of them, the other is deleted as well... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-428) Tenancy based access control - Delivery Service API
[ https://issues.apache.org/jira/browse/TC-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-428. --- Resolution: Fixed Fix Version/s: 2.1.0 > Tenancy based access control - Delivery Service API > --- > > Key: TC-428 > URL: https://issues.apache.org/jira/browse/TC-428 > Project: Traffic Control > Issue Type: Improvement > Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with "delivery-service as a resource". We enforce access > control via the API to the different users. > We also add a naive change in the UI - presenting the logged in user only > delivery-services users he has access to. > This JIRA does not deal with indirect tenancy (e.g DS/Regex table) - we will > deal with it in following JIRAs -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-459) User default tenancy should be "none"
[ https://issues.apache.org/jira/browse/TC-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-459. --- Resolution: Fixed Fix Version/s: 2.1.0 > User default tenancy should be "none" > - > > Key: TC-459 > URL: https://issues.apache.org/jira/browse/TC-459 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > Fix For: 2.1.0 > > > Currently the default tenancy is the tenancy if the creating user. > This may cause the creation of too powerful tenants by mistake. > Better give the new user no tenancy and set it later on -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-461) Delivery-service tenancy based access control - Steering Target
[ https://issues.apache.org/jira/browse/TC-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-461. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - Steering Target > --- > > Key: TC-461 > URL: https://issues.apache.org/jira/browse/TC-461 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops > Reporter: Nir Sopher > Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS steering target: In order to add a > steering target DS1 to steering DS ST1, the user should have access to the > tenants of DS1 and ST1. In order to read the record, access to ST1 is enough -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-460) Delivery-service tenancy based access control - DS/Server Assignment
[ https://issues.apache.org/jira/browse/TC-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-460. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - DS/Server Assignment > > > Key: TC-460 > URL: https://issues.apache.org/jira/browse/TC-460 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops > Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS assignment to servers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-463) Delivery-service tenancy based access control - DS/User Assignment
[ https://issues.apache.org/jira/browse/TC-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher reassigned TC-463: - Assignee: Nir Sopher > Delivery-service tenancy based access control - DS/User Assignment > --- > > Key: TC-463 > URL: https://issues.apache.org/jira/browse/TC-463 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops > Reporter: Nir Sopher > Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" as well > as "user as a resource" - enforcing via the API access control on DS to User: > The logged in user should have access to both the DS as well as the user > assigned to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-461) Delivery-service tenancy based access control - Steering Target
[ https://issues.apache.org/jira/browse/TC-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher reassigned TC-461: - Assignee: Nir Sopher > Delivery-service tenancy based access control - Steering Target > --- > > Key: TC-461 > URL: https://issues.apache.org/jira/browse/TC-461 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops > Reporter: Nir Sopher > Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS steering target: In order to add a > steering target DS1 to steering DS ST1, the user should have access to the > tenants of DS1 and ST1. In order to read the record, access to ST1 is enough -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-462) Delivery-service tenancy based access control - Regexes
[ https://issues.apache.org/jira/browse/TC-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher reassigned TC-462: - Assignee: Nir Sopher > Delivery-service tenancy based access control - Regexes > --- > > Key: TC-462 > URL: https://issues.apache.org/jira/browse/TC-462 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops > Reporter: Nir Sopher > Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS regexes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-471) Delivery-service tenancy based access control - ignore-tenancy parameter change
[ https://issues.apache.org/jira/browse/TC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-471. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - ignore-tenancy parameter > change > --- > > Key: TC-471 > URL: https://issues.apache.org/jira/browse/TC-471 > Project: Traffic Control > Issue Type: Improvement > Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > The "ignore-tenancy" variable comes to allow the disablement of the tenancy > mechanism. > It was decided to change the default of this variable to "true". It was also > decided to ignore the DS/User assignment if the "ignore-tenancy" is false. > During the transition, the user should set the tenancy of all DSes, > then enable tenancy, finalaly, he can clear the DS/User table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-471) Delivery-service tenancy based access control - ignore-tenancy parameter change
[ https://issues.apache.org/jira/browse/TC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher reassigned TC-471: - Assignee: Nir Sopher > Delivery-service tenancy based access control - ignore-tenancy parameter > change > --- > > Key: TC-471 > URL: https://issues.apache.org/jira/browse/TC-471 > Project: Traffic Control > Issue Type: Improvement > Reporter: Nir Sopher > Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > The "ignore-tenancy" variable comes to allow the disablement of the tenancy > mechanism. > It was decided to change the default of this variable to "true". It was also > decided to ignore the DS/User assignment if the "ignore-tenancy" is false. > During the transition, the user should set the tenancy of all DSes, > then enable tenancy, finalaly, he can clear the DS/User table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-485) Steering Target API - Redundent parameters
[ https://issues.apache.org/jira/browse/TC-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-485. --- Resolution: Fixed Fix Version/s: 2.1.0 > Steering Target API - Redundent parameters > -- > > Key: TC-485 > URL: https://issues.apache.org/jira/browse/TC-485 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 > Reporter: Nir Sopher > Fix For: 2.1.0 > > > Traffic Ops POST endpoint for "/api/1.2/steering" have the > delivery-service and target IDs in the path, but use the values retrieved as > parameters. > Therefore, these parameters needs to be removed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-478) Parameter value cannot be set to "0" using the parameters crud API
[ https://issues.apache.org/jira/browse/TC-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-478. --- Resolution: Fixed Fix Version/s: 2.1.0 > Parameter value cannot be set to "0" using the parameters crud API > -- > > Key: TC-478 > URL: https://issues.apache.org/jira/browse/TC-478 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Nir Sopher > Fix For: 2.1.0 > > > Example: > Having a parameter with value=="1" > Trying to "PUT" a value of "0" in this parameter. > The value of the parameter stays "1". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-462) Delivery-service tenancy based access control - Regexes
[ https://issues.apache.org/jira/browse/TC-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-462. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - Regexes > --- > > Key: TC-462 > URL: https://issues.apache.org/jira/browse/TC-462 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops > Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS regexes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-463) Delivery-service tenancy based access control - DS/User Assignment
[ https://issues.apache.org/jira/browse/TC-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-463. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - DS/User Assignment > --- > > Key: TC-463 > URL: https://issues.apache.org/jira/browse/TC-463 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops > Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" as well > as "user as a resource" - enforcing via the API access control on DS to User: > The logged in user should have access to both the DS as well as the user > assigned to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-427) Tenancy Based Access Control - User Resource
[ https://issues.apache.org/jira/browse/TC-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-427. --- Resolution: Fixed Fix Version/s: 2.1.0 > Tenancy Based Access Control - User Resource > > > Key: TC-427 > URL: https://issues.apache.org/jira/browse/TC-427 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API > Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with "user as a resource". We enforce access control via the > API to the different users. > We also add a naive change in the UI - presenting the logged in user only > users he has access to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-398) Create User API - Broken due to merge issue
[ https://issues.apache.org/jira/browse/TC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-398. --- Resolution: Fixed > Create User API - Broken due to merge issue > --- > > Key: TC-398 > URL: https://issues.apache.org/jira/browse/TC-398 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0 > Reporter: Nir Sopher >Assignee: Nir Sopher > Fix For: 2.1.0 > > > "Create" user API was recently added to TO. > Additionally, TO password hashing was changed to scrypt. > The merge between the 2 changes left the "create" command with the old "sha1" > calls. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-501) TPv2 installation - better defaults are required
Nir Sopher created TC-501: - Summary: TPv2 installation - better defaults are required Key: TC-501 URL: https://issues.apache.org/jira/browse/TC-501 Project: Traffic Control Issue Type: Bug Components: Traffic Portal Affects Versions: 2.1.0 Reporter: Nir Sopher After basic install of traffic-portal based on the documentation, traffic portal failed to launch. this is due to relative pathes to the logs and static files appear in the default configuration. Note that the working directory of the server is "/" First, the log path (./server/log) does not exists. A possible fix is to change the dir to /opt/traffic_portal/server/log and create the log dir if needed. Second. the files static path should be set to "opt/traffic_portal/public" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] incubator-trafficcontrol issue #776: fixes tenant test
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/776 10x! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #775: Clear tenants - to operate well ...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/775 Clear tenants - to operate well when the root tenant does not exists You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol use-tenancy-parameter Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/775.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #775 commit 1d45b220d3eaefade7e4bbc07e669f59d236c23b Author: nir-sopher <n...@qwilt.com> Date: 2017-08-03T22:07:22Z Clear tenants - to operate well when the root tenant does not exists --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #774: DS/USer table - tenancy checks -...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/774 DS/USer table - tenancy checks - PR review fixes Forgot a file in the commit... You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol user-tenancy-ds-assignment Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/774.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #774 commit 04df3d3f88776c664838a44a284b982a5f05bd9e Author: nir-sopher <n...@qwilt.com> Date: 2017-08-01T18:50:20Z DS/USer table - tenancy checks - PR review fixes --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #773: moving the use_tenancy parameter...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/773 moving the use_tenancy parameter to seed.sql WIP - not tested You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol use-tenancy-parameter Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/773.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #773 commit e25c02496d2f864456db09a944a873bf95df2a59 Author: nir-sopher <n...@qwilt.com> Date: 2017-08-01T19:51:16Z moving the use_tenancy parameter to seed.sql --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #753: [TC-463] User tenancy ds assignm...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/753#discussion_r131254521
--- Diff: traffic_ops/app/lib/API/User.pm ---
@@ -376,6 +387,10 @@ sub get_deliveryservices_not_assigned_to_user {
my $rs_links = $self->db->resultset("Deliveryservice")->search( undef,
{ order_by => "xml_id" } );
while ( my $row = $rs_links->next ) {
+ if
(!$tenant_utils->is_ds_resource_accessible_to_tenant($tenants_data,
$row->tenant_id, $user->tenant_id)) {
--- End diff --
OK, this is the last fix missing. On it
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #753: [TC-463] User tenancy ds assignm...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/753#discussion_r131245830
--- Diff: traffic_ops/app/lib/API/User.pm ---
@@ -376,6 +387,10 @@ sub get_deliveryservices_not_assigned_to_user {
my $rs_links = $self->db->resultset("Deliveryservice")->search( undef,
{ order_by => "xml_id" } );
while ( my $row = $rs_links->next ) {
+ if
(!$tenant_utils->is_ds_resource_accessible_to_tenant($tenants_data,
$row->tenant_id, $user->tenant_id)) {
--- End diff --
@mitchell852
We do not check the tenancy of the current user here.
Do you want to add it?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol issue #768: Tenant parent - on delete cascade
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/768 Thanks for the feedback Opening: https://github.com/apache/incubator-trafficcontrol/pull/771 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #768: Tenant parent - on delete cascad...
Github user nir-sopher closed the pull request at: https://github.com/apache/incubator-trafficcontrol/pull/768 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #771: Tenant table manual deletion, ta...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/771 Tenant table manual deletion, taking hierarchy into consideration You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol manual-cascade-delete-tenant Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/771.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #771 commit 0f6a2a52b525a99d403614d75e0598240bdc7de8 Author: nir-sopher <n...@qwilt.com> Date: 2017-08-01T10:13:11Z Tenant table manual cascade deletion --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #758: [TC-478] Parameter value can be ...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/758#discussion_r131065694
--- Diff: traffic_ops/app/lib/API/Parameter.pm ---
@@ -317,7 +317,7 @@ sub update {
my $name = $params->{name} || $find->name;
my $configFile = $params->{configFile} || $find->config_file;
-my $value = $params->{value} || $find->value;
+my $value = exists($params->{value}) ? $params->{value} :
$find->value;
--- End diff --
I would like to allow to set the value to 0.
**Apparently in Perl the string "0" is equivalent to False**
See
http://www.perlmonks.org/?node=what%20is%20true%20and%20false%20in%20Perl%3F
I can replace the "exists" with "defined" if you prefer. I believe that
logically "exists"is better, but it really does not matter for this case
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #751: [TC-462] Ds tenancy validation r...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/751#discussion_r130981656
--- Diff: traffic_ops/app/lib/API/DeliveryServiceRegexes.pm ---
@@ -222,6 +262,18 @@ sub delete {
return $self->forbidden();
}
+ my $ds = $self->db->resultset('Deliveryservice')->find( { id => $ds_id
} );
+ if ( !defined($ds) ) {
+ #allow deletion if the ds is not valid
--- End diff --
done
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol issue #768: Tenant parent - on delete cascade
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/768 Thanks for the feedback! I was struggling myself what is the correct solution (and therefore the wip) I started dealing with this issue as I noticed that when my UT crashes, prove can no longer be run until I "reset" the DB. The reason for that was that my UT added a child tenant to the defaults set of tenants, and crashed, leaving this tenant defined. When tear-down was called, the "delete table" for the "Tenant" table failed, trying to delete the parent tenant before the child. There are 2 ways I can see to fix this issue. 1. Write a custom "delete all tenants" function, to be used in tear-down. The function will delete the tenants in the correct order. 2. Use "ON DELETE CASCADE" - which seems to be common the common practice in traffic-ops DB. Is there another way to cascade delete the entire table for the sole usecase of tear-down? On Aug 1, 2017 8:02 PM, "Matt Mills" <notificati...@github.com> wrote: > In that case, why would this be an ON DELETE CASCADE, rather than an ON > DELETE RESTRICT? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/apache/incubator-trafficcontrol/pull/768#issuecomment-319432808>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AXGkYCI9DT9NHpZ-v7T93FxzqSvvZpFzks5sT1oSgaJpZM4Oow3L> > . > --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol issue #768: Tenant parent - on delete cascade
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/768 The change is in the db definition On Aug 1, 2017 7:42 PM, "Nir Sopher" <n...@qwilt.com> wrote: > Indeed. The api and the new portal does not allow tenant deletion if child > exists. > The legacy UI does not deal with tenacy at all. > > On Aug 1, 2017 7:34 PM, "Matt Mills" <notificati...@github.com> wrote: > >> IMO the UI should just throw an error when you try to delete a tenant >> that has children, rather than delete the children. >> >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> <https://github.com/apache/incubator-trafficcontrol/pull/768#issuecomment-319425246>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/AXGkYIFBna7AAQ3bvl_DoPdWvy0JvQh3ks5sT1N-gaJpZM4Oow3L> >> . >> > --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol issue #768: Tenant parent - on delete cascade
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/768 Indeed. The api and the new portal does not allow tenant deletion if child exists. The legacy UI does not deal with tenacy at all. On Aug 1, 2017 7:34 PM, "Matt Mills" <notificati...@github.com> wrote: > IMO the UI should just throw an error when you try to delete a tenant that > has children, rather than delete the children. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/apache/incubator-trafficcontrol/pull/768#issuecomment-319425246>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AXGkYIFBna7AAQ3bvl_DoPdWvy0JvQh3ks5sT1N-gaJpZM4Oow3L> > . > --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #768: Tenant parent - on delete cascad...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/768 Tenant parent - on delete cascade WIP: need to verify this is the right thing to do On tenant deletion, the child tenant are deleted automatically (via the DB). Note that we block tenant deletion by the API when it has a child tenants. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol tenant-parent-on-delet-cascade Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/768.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #768 commit 87f70d64f437c0ce9498722043ea464fbe815a87 Author: nir-sopher <n...@qwilt.com> Date: 2017-07-31T06:48:59Z Tenant parent - on delete cascade --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #751: [TC-462] Ds tenancy validation r...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/751#discussion_r130425792
--- Diff: traffic_ops/app/lib/API/DeliveryServiceMatches.pm ---
@@ -28,11 +29,19 @@ sub index {
my $format = $self->param("format") || "";
my $rs;
- if ( _privileged($self) ) {
+ # TO the reviewer: Do we need to override the "is_priviledged" here byt
the standard "ignore_ds_user_table" flag?
+ # What is the reason of the is_priv test - was someone just dussmissed
the ds_tmuser table tests
+ if ( _privileged($self)) {
--- End diff --
Check removed and UT adjusted
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #751: [TC-462] Ds tenancy validation r...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/751#discussion_r130420173
--- Diff: traffic_ops/app/lib/API/DeliveryServiceRegexes.pm ---
@@ -27,12 +28,18 @@ use Validate::Tiny ':all';
sub all {
my $self = shift;
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+
my $rs;
- if ( _privileged($self) ) {
+ if ( _privileged($self) or $tenant_utils->ignore_ds_users_table()) {
--- End diff --
OK.
Done in the relevant PR (which is pending the parameters fix PR)
I suggest this PR will be pulled and we will fix for all commits in the
relevant PRs
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol issue #402: [TC-184] Org tenancy - adding tenant to...
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/402 Closing for now, long way to go before we get to real CDN tenancy --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #402: [TC-184] Org tenancy - adding te...
Github user nir-sopher closed the pull request at: https://github.com/apache/incubator-trafficcontrol/pull/402 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #325: Adding an experimental go based ...
Github user nir-sopher closed the pull request at: https://github.com/apache/incubator-trafficcontrol/pull/325 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol issue #325: Adding an experimental go based rest AP...
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/325 no longer relevant --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol issue #230: [TC-121] Allowing variables in traffic-...
Github user nir-sopher commented on the issue: https://github.com/apache/incubator-trafficcontrol/pull/230 Closing from now, need to look further into the changes in the files generation code in order to fix --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #766: [TC-461] DS steering tenancy che...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/766 [TC-461] DS steering tenancy checks WIP Waiting to merge with PR 765 You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol ds-tenancy-validation-steering Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/766.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #766 commit 8bd9c437d2b50cd6dbe09b8b23050b15b625f483 Author: nir-sopher <n...@qwilt.com> Date: 2017-07-17T20:25:42Z DS steering tenancy checks --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (TC-485) Steering Target API - Redundent parameters
Nir Sopher created TC-485: - Summary: Steering Target API - Redundent parameters Key: TC-485 URL: https://issues.apache.org/jira/browse/TC-485 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0 Reporter: Nir Sopher Traffic Ops POST endpoint for "/api/1.2/steering" have the delivery-service and target IDs in the path, but use the values retrieved as parameters. Therefore, these parameters needs to be removed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130240113
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -947,6 +952,10 @@ sub details_v11 {
}
my $rs_ds_data = $row->deliveryservice_servers;
+ #FOR THE REVIEWER - Currently I do not check DS tenancy here.
--- End diff --
done
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130240112
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -1021,6 +1030,10 @@ sub details {
}
my $rs_ds_data = $row->deliveryservice_servers;
+ #FOR THE REVIEWER - Currently I do not check DS tenancy
here.
--- End diff --
done
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130239129
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -569,10 +575,17 @@ sub get_unassigned_servers_by_dsid {
$ds_server_criteria{'deliveryservice.id'} = $ds_id;
my @assigned_servers;
- if ( _privileged($self) ||
$self->is_delivery_service_assigned($ds_id) ) {
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+
+ if (!$tenant_utils->is_ds_resource_accessible($tenants_data,
$ds->tenant_id)) {
--- End diff --
Seems ok to me.
case 1: "use=tenancy" == true, and resource is accessible to tenant:
1. "if" test is false, continue
2. "elseif" test is true (as ignore_ds_users_table==true), so we get the
list of servers
case 2: "use=tenancy" == true, and resource is not accessible to tenant:
1. "if" test is true, return forbidden
case 3: "use=tenancy" == false, and ds is assigned to user
1. "if" test is false, continue
2. "elseif" test is true (as the ds is assigned to user), so we get the
list of servers
case 3: "use=tenancy" == false, and ds is not assigned to user
1. "if" test is false, continue
2. "elseif" test is false (as the ds is not assigned to user),
3. We reach the failure
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238813
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -726,41 +746,26 @@ sub get_servers_by_type {
my $orderby = $self->param('orderby') || "hostName";
my $orderby_snakecase = lcfirst( decamelize($orderby) );
+ my $forbidden;
--- End diff --
This function previously filtered records by the ds_user table (only
servers used for the DSes viewable to the user)
We agreed on mail to remove the test and put "is-oper"
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238764
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -569,10 +575,17 @@ sub get_unassigned_servers_by_dsid {
$ds_server_criteria{'deliveryservice.id'} = $ds_id;
my @assigned_servers;
- if ( _privileged($self) ||
$self->is_delivery_service_assigned($ds_id) ) {
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+
+ if (!$tenant_utils->is_ds_resource_accessible($tenants_data,
$ds->tenant_id)) {
+ return $self->forbidden();
+ }
+ elsif ( _privileged($self) || $tenant_utils->ignore_ds_users_table()
|| $self->is_delivery_service_assigned($ds_id) ) {
@assigned_servers =
$self->db->resultset('DeliveryserviceServer')->search( \%ds_server_criteria, {
prefetch => [ 'deliveryservice', 'server' ] } )->get_column('server')->all();
}
else {
+ #for the reviewer - I believe it should turn into forbidden as
well
--- End diff --
Fixed
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238784
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -651,7 +664,14 @@ sub get_eligible_servers_by_dsid {
my %ds_server_criteria;
$ds_server_criteria{'deliveryservice.id'} = $ds_id;
- if ( !_privileged($self) &&
!$self->is_delivery_service_assigned($ds_id) ) {
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+
+ if (!$tenant_utils->is_ds_resource_accessible($tenants_data,
$ds->tenant_id)) {
+ return $self->forbidden();
+ }
+ elsif ( !_privileged($self) &&
!$tenant_utils->ignore_ds_users_table() &&
!$self->is_delivery_service_assigned($ds_id) ) {
+ #for the reviewer - I believe it should turn into forbidden as
well
return $self->alert("Forbidden. Delivery service not assigned
to user.");
--- End diff --
done
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238734
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -489,11 +484,22 @@ sub get_edge_servers_by_dsid {
my $self= shift;
my $ds_id = $self->param('id');
+ my $ds = $self->db->resultset('Deliveryservice')->search( { 'me.id' =>
$ds_id } )->single();
+ if ( !defined($ds) ) {
+ return $self->not_found();
+ }
+
my $ds_servers;
- if ( _privileged($self) ||
$self->is_delivery_service_assigned($ds_id) ) {
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+ if (!$tenant_utils->is_ds_resource_accessible($tenants_data,
$ds->tenant_id)) {
+ return $self->forbidden();
--- End diff --
Done
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238728
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -445,18 +431,27 @@ sub get_servers_by_dsid {
my $orderby_snakecase = lcfirst( decamelize($orderby) );
my $helper= new Utils::Helper( { mojo => $self } );
+ my $ds = $self->db->resultset('Deliveryservice')->search( { 'me.id' =>
$ds_id }, { prefetch => ['type'] } )->single();
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+
my @ds_servers;
my $forbidden;
- if ( _privileged($self) ||
$self->is_delivery_service_assigned($ds_id) ) {
+ my $servers;
+
+ if (defined($ds) &&
!$tenant_utils->is_ds_resource_accessible($tenants_data, $ds->tenant_id)) {
+ $forbidden = "Forbidden. Delivery service not available for
user's tenant.";
+ return ($forbidden, $servers);
+ }
+ elsif ( _privileged($self) || $tenant_utils->ignore_ds_users_table()
|| $self->is_delivery_service_assigned($ds_id) ) {
--- End diff --
Same, answer:)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238709
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -400,40 +401,25 @@ sub get_servers_by_status {
my $orderby = $self->param('orderby') || "hostName";
my $orderby_snakecase = lcfirst( decamelize($orderby) );
+ my $forbidden;
--- End diff --
This function tested the "ds_user" table and filtered DSes accordingly.
We discussed it (by mail) and decided to remove this test and add only a
"is-oper" test
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238653
--- Diff: traffic_ops/app/lib/API/Server.pm ---
@@ -400,40 +401,25 @@ sub get_servers_by_status {
my $orderby = $self->param('orderby') || "hostName";
my $orderby_snakecase = lcfirst( decamelize($orderby) );
+ my $forbidden;
--- End diff --
The function was previously testing the ds_user table as well and filtering
by it.
We agreed it should be removed and replaced only with "is-oper" test
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238561
--- Diff: traffic_ops/app/lib/API/DeliveryServiceServer.pm ---
@@ -223,8 +240,19 @@ sub remove_server_from_ds {
my $ds_id = $self->param('dsId');
my $server_id = $self->param('serverId');
- if ( !_privileged($self) &&
!$self->is_delivery_service_assigned($ds_id) ) {
- $self->forbidden("Forbidden. Delivery service not assigned to
user.");
+ my $tenant_utils = Utils::Tenant->new($self);
+ if ( !_privileged($self) && !$tenant_utils->ignore_ds_users_table()
&& !$self->is_delivery_service_assigned($ds_id) ) {
--- End diff --
Probably yes, we need to decide if we merge only the 2 parameters
(use-tenancy & ignore_ds_user_assignment) or the functions as well.
If we merge also the fucntions, lets do it in one "search replace" commit
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r130238531
--- Diff: traffic_ops/app/lib/API/DeliveryServiceServer.pm ---
@@ -80,15 +86,21 @@ sub assign_servers_to_ds {
return $self->forbidden();
}
- if ( ref($servers) ne 'ARRAY' ) {
- return $self->alert("Servers must be an array");
- }
-
my $ds = $self->db->resultset('Deliveryservice')->find( { id => $ds_id
} );
if ( !defined($ds) ) {
return $self->not_found();
}
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+ if (!$tenant_utils->is_ds_resource_accessible($tenants_data,
$ds->tenant_id)) {
+ return $self->alert("Invalid delivery-service assignment. The
delivery-service is not avaialble for your tenant.");
--- End diff --
Are you sure?
This is not part of the path
$r->post("/api/$version/deliveryserviceserver")->over( authenticated => 1,
not_ldap => 1 )->to( 'DeliveryServiceServer#assign_servers_to_ds', namespace =>
$namespace );
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #751: [TC-462] Ds tenancy validation r...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/751#discussion_r130237388
--- Diff: traffic_ops/app/lib/API/DeliveryServiceRegexes.pm ---
@@ -222,6 +262,18 @@ sub delete {
return $self->forbidden();
}
+ my $ds = $self->db->resultset('Deliveryservice')->find( { id => $ds_id
} );
+ if ( !defined($ds) ) {
+ #allow deletion if the ds is not valid
--- End diff --
If sue to some bug or inconsitency - the a regex exists but the parent DS
does not, we cannot check tenancy.
However we want to allow the deletion of the regex - which for itself
exists.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #751: [TC-462] Ds tenancy validation r...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/751#discussion_r130237244
--- Diff: traffic_ops/app/lib/API/DeliveryServiceRegexes.pm ---
@@ -66,6 +73,12 @@ sub index {
return $self->not_found();
}
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+ if (!$tenant_utils->is_ds_resource_accessible($tenants_data,
$ds->tenant_id)) {
+ return $self->forbidden();
--- End diff --
yes, this code was written before we discussed this issue. Will fix in all
3 PRs
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #751: [TC-462] Ds tenancy validation r...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/751#discussion_r130237223
--- Diff: traffic_ops/app/lib/API/DeliveryServiceRegexes.pm ---
@@ -27,12 +28,18 @@ use Validate::Tiny ':all';
sub all {
my $self = shift;
+ my $tenant_utils = Utils::Tenant->new($self);
+ my $tenants_data = $tenant_utils->create_tenants_data_from_db();
+
my $rs;
- if ( _privileged($self) ) {
+ if ( _privileged($self) or $tenant_utils->ignore_ds_users_table()) {
--- End diff --
This code was written earlier...
BTW, I thought you were just concerned about having 2 separate parameters.
Would you like to merge the "use-tenancy" and "ignore-ds-user-table" functions
as well?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #751: [TC-462] Ds tenancy validation r...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/751#discussion_r130237222
--- Diff: traffic_ops/app/lib/API/DeliveryServiceMatches.pm ---
@@ -28,11 +29,19 @@ sub index {
my $format = $self->param("format") || "";
my $rs;
- if ( _privileged($self) ) {
+ # TO the reviewer: Do we need to override the "is_priviledged" here byt
the standard "ignore_ds_user_table" flag?
+ # What is the reason of the is_priv test - was someone just dussmissed
the ds_tmuser table tests
+ if ( _privileged($self)) {
--- End diff --
I was trying to keep the functionality as is, and just add the tenancy
tests.
Do you know why was it restricted to a privileged user in the first place?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/752#discussion_r129928084
--- Diff: traffic_ops/app/lib/API/DeliveryServiceServer.pm ---
@@ -27,6 +28,11 @@ sub index {
my @data;
my $orderby = $self->param('orderby') || "deliveryservice";
+ #FOR THE REVIEWER - Currently I do not check DS tenancy here.
--- End diff --
As I saw it, the ds-admin should not be aware of specific servers
existence, so this API should not be available to him.
However, as you see usecases a ds-admin may approach this API, I'll had the
tenancy check
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-trafficcontrol pull request #759: [TC-471] Tenancy - disabled by d...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/759 [TC-471] Tenancy - disabled by default. When enabled - DS/User assign not active WIP Pending PR-758 to allow UT. Still need to add the parameter as "0" to the seed.sql You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol use-tenancy-parameter Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/759.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #759 commit 74c86a66a9f96f159f80092f02b4ea20abcddf8f Author: nir-sopher <n...@qwilt.com> Date: 2017-07-23T07:52:04Z Tenancy - disabled by default. When enabled - DS/User table is no longer active --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #758: [TC-478] Parameter value can be ...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/758 [TC-478] Parameter value can be changed to 0 You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol parameter-value-can-change-to-0 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/758.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #758 commit 5381c7b944be55a062aeecf7fe0aee298ed5f598 Author: nir-sopher <n...@qwilt.com> Date: 2017-07-23T07:47:54Z Parameter value can be changed to 0 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (TC-478) Parameter value cannot be set to "0" using the parameters crud API
Nir Sopher created TC-478: - Summary: Parameter value cannot be set to "0" using the parameters crud API Key: TC-478 URL: https://issues.apache.org/jira/browse/TC-478 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0 Reporter: Nir Sopher Example: Having a parameter with value=="1" Trying to "PUT" a value of "0" in this parameter. The value of the parameter stays "1". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] incubator-trafficcontrol pull request #753: [TC-463] User tenancy ds assignm...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/753 [TC-463] User tenancy ds assignment You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol user-tenancy-ds-assignment Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/753.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #753 commit 99a8dbd0fab50b6aec8d861d0781f01f20461b35 Author: nir-sopher <n...@qwilt.com> Date: 2017-06-21T01:09:00Z DS/User table - user tenancy verification commit c65ffe5c27e2f9ccecc6989672609776d95daaa7 Author: nir-sopher <n...@qwilt.com> Date: 2017-06-26T15:27:24Z DS tenancy - almost no effect on DS/Tmuser operation commit 89db4545afdcd9440b8aee8e8acf198536004a33 Author: nir-sopher <n...@qwilt.com> Date: 2017-06-28T03:04:18Z Moving to UI::TenantUtils to Utils::Tenant, and changeing assign_user tenancy check error to 400 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #752: [TC-460] Ds tenancy validation s...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/752 [TC-460] Ds tenancy validation server You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol ds-tenancy-validation-server Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/752.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #752 commit 941641a880888bc504b2f3012433de86629a43fc Author: nir-sopher <n...@qwilt.com> Date: 2017-07-04T15:32:41Z DS/Server tenancy check (DS based) - not tested commit c14f17c386abf0bdf865d19b4141091c3ca874f8 Author: nir-sopher <n...@qwilt.com> Date: 2017-07-05T08:52:34Z DS/Server tenancy - tests commit cfa4104ea5af12dda1c8fb98896f99ba99dea32e Author: nir-sopher <n...@qwilt.com> Date: 2017-07-05T14:16:06Z DS/Server tenancy checks - additional endpoints commit fb62c8cb5e416a2cdb58bd071d5c98ea0e9e04b2 Author: nir-sopher <n...@qwilt.com> Date: 2017-07-20T13:29:41Z DS/Server tenancy checks - UT fixes after rebase --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #751: [TC-462] Ds tenancy validation r...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/751 [TC-462] Ds tenancy validation regex You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol ds-tenancy-validation-regex Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/751.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #751 commit bf90642b77c22c9db78bbc80115fe11753d16374 Author: nir-sopher <n...@qwilt.com> Date: 2017-06-26T10:51:39Z DS tenancy validation - regexes API commit 33779ade730a3597ee33f6bb12b7e41a1bf192d2 Author: nir-sopher <n...@qwilt.com> Date: 2017-07-04T15:33:46Z Tenancy check - deliver-service-match --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-trafficcontrol pull request #750: [TC-459] User default tenancy - ...
GitHub user nir-sopher opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/750 [TC-459] User default tenancy - undef You can merge this pull request into a Git repository by running: $ git pull https://github.com/nir-sopher/incubator-trafficcontrol user-tenancy-default Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafficcontrol/pull/750.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #750 commit b0a61254aa94fa700c354c156ad90ff69d6a2899 Author: nir-sopher <n...@qwilt.com> Date: 2017-07-22T03:13:21Z User default tenancy - undef --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (TC-464) Delivery-service tenancy based access control - Federation
[ https://issues.apache.org/jira/browse/TC-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-464: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing access control on Federations. We still need to finalize the specification of this access control.the TC was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on Federations. We still need to finalize the specification of this access control.the TC > Delivery-service tenancy based access control - Federation > -- > > Key: TC-464 > URL: https://issues.apache.org/jira/browse/TC-464 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing access control on Federations. > We still need to finalize the specification of this access control.the TC -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-466) Delivery-service tenancy based access control - statidnsentry
[ https://issues.apache.org/jira/browse/TC-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-466: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing access control on static-dns-entry, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries of DSes which are not under his tenancy. was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on static-dns-entry, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries of DSes which are not under his tenancy. > Delivery-service tenancy based access control - statidnsentry > - > > Key: TC-466 > URL: https://issues.apache.org/jira/browse/TC-466 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing access control on static-dns-entry, according to their Delivery > service. > We still need to finalize the specification of this access control, and it > would not be included in the first phase of tenancy introduction, assuming > that the application hide from the user the ability to deal with entries of > DSes which are not under his tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-467) Delivery-service tenancy based access control - DNSSEC and SSL Keys
[ https://issues.apache.org/jira/browse/TC-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-467: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing access control on the management of ssl keys and DNSSEC, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries relating to DSes which are not under his tenancy. was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on the management of ssl keys and DNSSEC, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries relating to DSes which are not under his tenancy. > Delivery-service tenancy based access control - DNSSEC and SSL Keys > --- > > Key: TC-467 > URL: https://issues.apache.org/jira/browse/TC-467 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing access control on the management of ssl keys and DNSSEC, according > to their Delivery service. > We still need to finalize the specification of this access control, and it > would not be included in the first phase of tenancy introduction, assuming > that the application hide from the user the ability to deal with entries > relating to DSes which are not under his tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-465) Delivery-service tenancy based access control - JOBs
[ https://issues.apache.org/jira/browse/TC-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-465: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing access control on Jobs, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with DSes which are not under his tenancy. was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on Jobs, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with DSes which are not under his tenancy. > Delivery-service tenancy based access control - JOBs > > > Key: TC-465 > URL: https://issues.apache.org/jira/browse/TC-465 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing access control on Jobs, according to their Delivery service. > We still need to finalize the specification of this access control, and it > would not be included in the first phase of tenancy introduction, assuming > that the application hide from the user the ability to deal with DSes which > are not under his tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-469) User tenancy based access control - log
[ https://issues.apache.org/jira/browse/TC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-469: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "user as a resource" - enforcing access control to log records, according to their user tenancy. was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "user as a resource" - enforcing via the API access control , according to their Delivery service.to the log records with proper user tenancy. > User tenancy based access control - log > --- > > Key: TC-469 > URL: https://issues.apache.org/jira/browse/TC-469 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "user as a resource" - enforcing access > control to log records, according to their user tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-469) User tenancy based access control - log
Nir Sopher created TC-469: - Summary: User tenancy based access control - log Key: TC-469 URL: https://issues.apache.org/jira/browse/TC-469 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "user as a resource" - enforcing via the API access control , according to their Delivery service.to the log records with proper user tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-466) Delivery-service tenancy based access control - statidnsentry
Nir Sopher created TC-466: - Summary: Delivery-service tenancy based access control - statidnsentry Key: TC-466 URL: https://issues.apache.org/jira/browse/TC-466 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on static-dns-entry, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries of DSes which are not under his tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-464) Delivery-service tenancy based access control - Federation
Nir Sopher created TC-464: - Summary: Delivery-service tenancy based access control - Federation Key: TC-464 URL: https://issues.apache.org/jira/browse/TC-464 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on Federations. We still need to finalize the specification of this access control.the TC -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-463) Delivery-service tenancy based access control - DS/User Assignment
Nir Sopher created TC-463: - Summary: Delivery-service tenancy based access control - DS/User Assignment Key: TC-463 URL: https://issues.apache.org/jira/browse/TC-463 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" as well as "user as a resource" - enforcing via the API access control on DS to User: The logged in user should have access to both the DS as well as the user assigned to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-462) Delivery-service tenancy based access control - Regexes
Nir Sopher created TC-462: - Summary: Delivery-service tenancy based access control - Regexes Key: TC-462 URL: https://issues.apache.org/jira/browse/TC-462 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on DS regexes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
