<M|tar>
where does one configure which permissions/roles do users through a share link get?
chilts has quit [Ping timeout: 244 seconds]
M|tar is now known as Mitar
bemasc_ has quit [Ping timeout: 244 seconds]
bemasc has joined #sandstorm
mrdomino has quit [Ping timeout: 244 seconds]
Mitar is now known as M|tar
M|tar is now known as Mitar
mrdomino has joined #sandstorm
chilts has joined #sandstorm
dcb_ has quit [Disconnected by services]
dcb has joined #sandstorm
bencevans has quit [Ping timeout: 276 seconds]
bencevans has joined #sandstorm
bencevans has joined #sandstorm
nolski has quit [Ping timeout: 276 seconds]
nolski has joined #sandstorm
raoulzecat has quit [Ping timeout: 246 seconds]
xet7 has quit [Ping timeout: 276 seconds]
ripdog has quit [Ping timeout: 276 seconds]
ripdog has joined #sandstorm
xet7 has joined #sandstorm
xet7 has quit [Client Quit]
xet7 has joined #sandstorm
jemc has joined #sandstorm
raoulzecat has joined #sandstorm
amyers has joined #sandstorm
raoulzecat has quit [Ping timeout: 250 seconds]
amyers has quit [Ping timeout: 268 seconds]
mnutt_ has joined #sandstorm
BigShip has joined #sandstorm
mnutt_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nolski has quit [Ping timeout: 250 seconds]
nolski has joined #sandstorm
BigShip has quit [Remote host closed the connection]
bencevans has quit [*.net *.split]
bencevans has joined #sandstorm
bencevans has joined #sandstorm
mnutt_ has joined #sandstorm
BigShip has joined #sandstorm
mnutt_ has quit [Client Quit]
<nwf>
Mitar: When you create a link, there will be a dropdown of rights; having already shared a link, you can click "See who has access" and alter the permissions as your heart desires. :)
<nwf>
Er, hm, perhaps my memory is faulty and the first half of that is a lie. The second half is correct, at least.
<nwf>
Oh, no, there it goes; the UI just took a while to load.
<kentonv>
if the app hasn't defined any permissions then there's no dropdown. There's also no dropdown briefly while the app is loading and it hasn't told us its permission set yet; we should fix that.
dcb- has joined #sandstorm
prettyvanilla has quit [Ping timeout: 244 seconds]
dcb has quit [*.net *.split]
prettyvanilla has joined #sandstorm
BigShip has quit [*.net *.split]
bencevans has quit [*.net *.split]
bencevans has joined #sandstorm
bencevans has joined #sandstorm
BigShip has joined #sandstorm
BigShip has joined #sandstorm
frigginglorious has joined #sandstorm
achernya has joined #sandstorm
raoulzecat has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
wolcen has joined #sandstorm
frigginglorious has joined #sandstorm
BigShip has quit [Remote host closed the connection]
Psy-Q has quit [Ping timeout: 276 seconds]
BigShip has joined #sandstorm
Psy-Q has joined #sandstorm
prettyvanilla has quit [Ping timeout: 250 seconds]
prettyvanilla has joined #sandstorm
raboof has quit [Ping timeout: 260 seconds]
raboof has joined #sandstorm
<Mitar>
ah, this will be it, I have not yet defined them in the file :-)
<Mitar>
oh, no, I defined them, but I have not defined roles
<Mitar>
so just permissions are not enough?
<dwrensha>
yes, you need to define roles for the dropdown to show up in the UI, currently
jemc has quit [Ping timeout: 244 seconds]
BigShip has quit [Remote host closed the connection]
wolcen has quit [Ping timeout: 276 seconds]
Psy-Q has quit [Ping timeout: 250 seconds]
Psy-Q has joined #sandstorm
frigginglorious has quit [*.net *.split]
achernya has quit [*.net *.split]
digitalcircuit has quit [Remote host closed the connection]
digitalcircuit has joined #sandstorm
<zarvox>
Lord: hmmm, does your kernel or runtime environment disallow the unshare() syscalls? are you running this on hardware, or somewhere else, like a Docker container where those container-creating syscalls might be restricted?
<Lord>
i tried in an alpine lxc container
<Lord>
alpine doesn't use glibc but musl. I think that's perhaps the cause of this
<zarvox>
I think not; your error message is from a kernel syscall returning failure for something we expect to work.
<Lord>
i may try on my computer
<zarvox>
For what Sandstorm depends on at runtime, we provide our own glibc.
<Lord>
(not tonight but maybe tomorrow)
<Lord>
how to know if unshare() works or not ?
<zarvox>
there's an "unshare" program in util-linux; try `unshare -p` as the sandstorm user from within the container?
<Lord>
operation not permitted
<Lord>
ok
Psy-Q has quit [Ping timeout: 276 seconds]
Psy-Q has joined #sandstorm
prettyvanilla_ has joined #sandstorm
mrdomino_ has joined #sandstorm
ripdog_ has joined #sandstorm
prettyvanilla has quit [*.net *.split]
ripdog has quit [*.net *.split]
chilts has quit [*.net *.split]
mrdomino has quit [*.net *.split]
ripdog_ is now known as ripdog
wolcen has joined #sandstorm
<Mitar>
about anonymous users with permissions, I am not sure how exactly app can support them
<Mitar>
at least in my app, if user has permissions, then they can do something: add some content, for example
<Mitar>
but anonymous users do not have an uid which I could use to reference those changes to the user
<Mitar>
(at least how I read docs)
<Mitar>
I think it should be transparent to the app if user is normal one or anonymous
<zarvox>
Rocket.Chat, for instance, requires that you not be anonymous.
<Mitar>
I do not know of any app which would not use some form of references to an user object for created content
<Mitar>
yes, but this is bad, this means app has power to do that
<Mitar>
if sandstorm would simply make one-off users for those who would be anonymous, then app would not have a power to know that
<Mitar>
and users would be really be able to be anonymous
<Mitar>
plus, apps would not have to change any of their logic to handle anonymous users
<Mitar>
now I would have to do a lot of changes to handle that case
<Mitar>
for example, allowing anonymous commenting, I would be ok with app allowing that, but please, let me have some random uid so that I do not have to do extra work to implement this
<zarvox>
kentonv: ^ would be interested to hear your opinion on the above
<digitalcircuit>
Alternatively, should allowing anonymous users be something Sandstorm handles, apps could suggest a default setting of "yes" or "no", and users can override that?
ckocagil_ has quit [Ping timeout: 260 seconds]
ckocagil has joined #sandstorm
<kentonv>
if you need an ID for an anonymous user, the right wan to use is tabId
<kentonv>
however, different apps will likely make different decisions about how to handle anonymous access
<kentonv>
I don't think there's any one-size-fits-all answer here
<zarvox>
I think most apps don't think about anonymous users as being allowed to make changes, in general. To the extent that apps *do* want to support anonymous interactions, I think it's broadly up to the app to decide how to model that - some will stub out an anonymous user, some will null out that field, etc.
<kentonv>
wtf how did I try to type "one" and right "wan"?
<pdurbin>
obi one kenobi
<zarvox>
obi-one kenobi
<zarvox>
pdurbin++
<pdurbin>
zarvox: jinx!
<kentonv>
... right -> write
<kentonv>
fuuuuuuuuuuuuuuuuuuu
<digitalcircuit>
Need some rest..? :)
<Mitar>
but tabId is not of the same "type" as uid, my type checking in the head fails here :-)
<Mitar>
and also, are they unique across sessions?
<Mitar>
why wouldn't just sandstorm hide the fact that user is anonymous from the app?
sydney_untangle has quit [Ping timeout: 260 seconds]
<Mitar>
simply provide the same fields, with permissions, and everything
<Mitar>
only uid would be different between different sessions
<Mitar>
there could be an extra parameter passed to tell app if user is anonymous
<Mitar>
if they want to handle it differently
<Mitar>
but I think it is a better default
<Mitar>
than the other, where app has to implement all special logic if they want to handle anonymous users differently
jadewang has joined #sandstorm
<Mitar>
also, sandstorm anonymous users are different than normal anonymous users
<Mitar>
it is something platform hides from the app
<kentonv>
not all apps should treat anonymous users the same as others
<kentonv>
if it makes sense for your app, then it's easy enough to say: userId != null ? userId : tabId
<Mitar>
is tabid of the same type as userid?
<kentonv>
they're both long hex strings
<kentonv>
they will never collide
<Mitar>
and tabids between sessions will never collide either?
<kentonv>
correct
<kentonv>
if they do it's a security bug
<Mitar>
and I agree that different apps have different needs, what I am saying is that default should be different
<kentonv>
sorry, I just don't agree.
<kentonv>
having seen a lot of apps
<Mitar>
that it would be easier to have anonymous users behave like normal, especially because in sandstorm anonymous users can have permissions as well
<kentonv>
most apps want to treat anonymous users differently
<Mitar>
but those apps do not have sandstorm tell them what permissions should that anonymous user have
<kentonv>
a lot of Sandstorm apps automatically create user entries in the database every time they see a different user ID, but don't want to fill up the database with records for every anonymous session
sydney_untangle has joined #sandstorm
<Mitar>
if you want apps where sandstorm can tell what permissions anonymous users have, then the logic path for such anonymous users is much more similar to normal users
<kentonv>
for apps where permissions are really everything, then it makes sense for the app to ignore userId entirely
<Mitar>
yes, but they will have to create that entry when that user will want to do something with a permission they have
<Mitar>
so instead of changing whole logic to lazily do those entries
<Mitar>
probably they will just do it so that you create entry always, and have some background job to clean inactive users, because that cron job you anyway already have for normal users, in most cases, anyway
<kentonv>
many apps do *not* need to record users
<kentonv>
e.g. TextEditor does not record anything about users. It just lets you edit the content if you have the permission.
<Mitar>
many collaborative apps do have to record which user made which change, no?
<kentonv>
some do, some don't
<kentonv>
it's a big feature and sometimes the app just isn't meant to be that complicated
<Mitar>
exactly, so those who do not, would simply ignore uid for normal users and anonymous users
<Mitar>
does who do, would have easier time implementing their stuff if sandstorm would provide uid for both types of users
<kentonv>
look I'm sorry but this cannot change. We would break existing apps if we started creating random user IDs for anonymous users.
<Mitar>
i thought that you are in beta for the reason that you can still introduce breaking changes?
<kentonv>
no, we will not break old apps
<kentonv>
the very first app ever packaged still works
<Mitar>
hmm, tricky
<kentonv>
I mean, if we decide an API is wrong, we can do a thing with a compatibility shim. But this API isn't wrong.
<Mitar>
would you be open for meteor package for user accounts to accept a pull request which would make this a configuration option?
<Mitar>
to sync anonymous users into users collection based on tabid?
<Mitar>
and that then my app can simply use Meteor.user() and just work?
<kentonv>
that sounds reasonable.
<Mitar>
ok, do you have a preferred way to configure this? env variable? meteor settings? some Call.fromSourceFile(true)?
<Mitar>
for other accounts package is often the latter
<kentonv>
a function call (intended to be called at startup) sounds best
<Mitar>
ok
<kentonv>
note that I think accounts-sandstorm doesn't handle tabId at all yet (since it's pretty new), but you should be able to add it easily.
<Mitar>
ok
<Mitar>
hm, but tabid is not the same for multiple tabs of the same anonymous user, no?
<Mitar>
hm, ok, tabid is based on sidebar tab, not on browser tabs
<Mitar>
do browser tabs share the same tabid?
<Mitar>
in the same browser, during same session?
<dwrensha>
no
<Mitar>
oh, then this is not the right value to use for anonymous users :-(
<Mitar>
because normal users would have the same uid, no?
<Mitar>
it would be really strange for users to open grain in two browser tabs and would not be seen as the same user for the app
<dwrensha>
that's part of what it means to be anonymous
<Mitar>
hm, anonymous between sessions
<Mitar>
not between tabs
<Mitar>
even in private browsing mode in browsers
<Mitar>
tabs in the same window share information
<Mitar>
if they would not, it would be completely confusing to users
<Mitar>
ah, I wanted to make a Sandstorm-first Meteor app, but I see that some design decisions really makes it hard to use all features in a sensible way :-(
<Mitar>
ok, back to simply ignoring anonymous users
<Mitar>
I prefer them losing anonymity over having strange user experience
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]
chilts has joined #sandstorm
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]