cartoframes: [bug] cc.write(overwrite=True) affecting permissions
For carto version <=0.6.2
I am seeing the following strange behaviour.
If I overwrite a dataset using cc.write(df,"dataset",overwrite=True)
then any share permissions on the updated dataset
stop working.
You can test it as follows:
# pipenv install "cartoframes<=0.6.2" jupyter --skip-lock
import cartoframes
from cartoframes import Credentials
import pandas as pd
import requests
# ---Setup two users one is the dataset owner the second has the dataset shared with it---
privateuser="privateuser"
private_url="https://privateuser.carto.com"
private_api_key="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
publicuser="publicuser"
public_url="https://publicuser.carto.com"
public_api_key="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
cc = cartoframes.CartoContext(base_url=private_url, api_key=private_api_key)
private_dataset = "private_table"
df = cc.read(private_dataset)
updated_df = df
updated_df.value = round(df.value*1000)
# Write and fetch
url = f'{public_url}/api/v2/sql?q=SELECT * FROM "{privateuser}".{private_dataset} LIMIT 10&api_key={public_api_key}'
# Before the write the URL works fine
r = requests.get(url)
r.status_code == 200
cc.write(updated_df, private_dataset, overwrite = True)
# After the write the URL returns 401 permission denied
r = requests.get(url)
r.status_code == 401
r.content
# b'{"error":["permission denied for relation private_table"]}'
In the rails app the ACL/Permissions record for the dataset hasn’t changed. So I don’t understand why it would reset the permission when querying via the sql api?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 26 (24 by maintainers)
Ok, it’s confirmed: if you create an api key for a dataset, then do a cartoframes write operation with overwrite, then that invalidates the api key/table combo.
This is a feature of the Auth API that I wasn’t aware of until now. To prevent this from happening in cartoframes would require a non-trivial refactoring of the code as well. We’re going to put our heads together and figure out a solution and ping back here because the behavior you are expecting is what should be in place.
cc @inigomedina
I like the idea. We could even move deeper doing
truncate
the default one and making the DROP + CREATE the “special” case (only for cases when the data structure has changed (user will be responsible of choosen the right option))