-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Oso 0.26 - Issue with entities appearing multiple times in a relation #1531
Comments
Hey, thanks for the super detailed issue. The other one is a limitation of the new data filtering right now. It can only join to each table once. We want to expand that in the future but that's how it is right now. |
Good. Well, if you can improve this, it's great. The user experience would be better. Meanwhile, we can live with it. We just need to alias the join we append to the query.
I'm not sure I understand that part, and I'd surely appreciate a hint. The polar file is here. Relevant part would be:
The admin may associate users and campaigns, campaigns and TSCG, and users and TSCG. The user may read Campaign x TSCG associations if he is a member of (i.e. associated with) both the campaign and the TSCG. This is how I specify the rules. And I believe this is why the query builder joins twice on user. Maybe the way I build the polar file is wrong. It is mostly based on trial and error + extensive unit tests.
Oh, you mean the Thanks. |
Yeah I believe this is what @saolsen was getting at — that you could invert the relations so that you're going from, e.g., |
Hi. Thanks for the help on this. I just changed
into
and the test now passes. Good. Yet, I have the feeling that I'm getting away with it this time but the same issue might strike again anytime and it won't be obvious why it doesn't work and what relation will work, if any. As @saolsen said, this is a workaround. In other words, I consider the problem still exists, but the workaround at least allows me to move on. This and #1536 currently prevent me from moving to 0.26 / |
As I expected, I just got hit by this again. My model has this kind of loop / diamond relation (those loops always make me cringe but that how it is):
User groups associate users with both A1 and B1 objects, which defines user access to A2 and B2 respectively. The permissions on AB association table depend on both permissions on A2 and B2 and I'm getting the dreaded
Nothing new and surprising, I'm afraid. This time, I could get away with it because a business rule implies that read permissions on A involves read permissions on B so I could skip the check on B, but this is very specific and I'm afraid as the model grows, this will become a real blocker.
I assume the case above is pretty common in real-life models so this must be a major drawback, isn't it? I guess there are technical reasons for this current limitation and I totally understand Oso is young and you can't get the whole thing done right away, but I'm curious about your roadmap, more specifically, is this a high-priority feature you aim at supporting soon or is it a low-priority improvement that might be achieved some day eventually? Or is this actually a corner case I could avoid with a better model or a better use of Oso? |
It is a pretty common thing for people to run into so is a big drawback of the current data filtering. We're focused on some other things right now so I don't really have a good answer for when we'll get to it. |
Hi.
I'm still having issues migrating to 0.26.
I modified my code to use
It won't work with 0.25 (#1520) so I can't tell for sure if the difference comes from the use of
SqlAlchemyAdapter
or from 0.25 vs. 0.26.Apparently there has been an important rework in the way the SQL queries are built. I can see that 0.26 generates simpler queries where 0.25 uses subqueries.
A first consequence of this is that when building upon a query generated with
authorized_query
I had issues if I added joins with tables that were already used inside the authorization logic, therefore already used in the query.This would take the form of
I solved this by aliasing the tables I join.
Basically,
becomes
I'm not proficient with SQLAlchemy but I'm thinking perhaps Oso could alias tables in the first place so that the user could use classes directly without bothering. It is nice (in fact, fantastic) that Oso does the SQL stuff for us but having to alias tables used in the auth logic kind of makes the abstraction leak. To be on the safe side, I can alias all tables in joins appended to Oso-generated queries, but it is a pity.
Now I'm facing another issue that might be related.
I have a model in which User relates to both A and B, and A and B themselves are related. I define permissions allowing the user to read AxB association table. The rule is that if user has read permission on both A and B, they can read AxB association.
I'm getting this error:
I printed a trace but it is a bit hard for me to unravel. Anyway, my guess is that user appears twice because it is involved in both userxA and userxB relations.
Here's a trace line before the error:
I'm thinking it could be related to the first issue because in both cases an entity appears twice. In the first case, the second appearance appears in my code and I get an SQLAlchemy error, while here it all happens in Oso and I get a polar error.
I didn't take the time to build a minimal reproducible example and I hope I'm (making sense and I'm) giving enough details.
I don't mind linking to the project if it helps, it is public anyway, but I don't expect someone to be willing to dive into it.
Anything else I could provide?
Thanks.
The text was updated successfully, but these errors were encountered: