Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 11 2021 20:52
    @RubenVerborgh banned @mikeadams1
  • Jan 04 2021 20:23
    @RubenVerborgh banned @WebCivics_twitter
  • Jan 04 2021 20:18
    @RubenVerborgh banned @SailingDigital_twitter
  • May 27 2019 06:08
    User @Mitzi-Laszlo unbanned @in1t3r
  • May 23 2019 06:49
    @Mitzi-Laszlo banned @in1t3r
  • May 16 2019 09:49
    @Mitzi-Laszlo banned @mediaprophet
  • Feb 01 2019 22:04
    User @melvincarvalho unbanned @namedgraph_twitter
  • Feb 01 2019 21:49
    @melvincarvalho banned @namedgraph_twitter
Dmitri Zagidulin
@dmitrizagidulin
the .catches() fire in order
so you can place your own .catch() earlier in the chain
passing in a reject callback function won't save you in this case
(aside from teh fact that its use is discouraged)
elf Pavlik
@elf-pavlik
so if you catch rejected promise, and return resolved the next catch will still catch that rejected promise ?
in one of the videos about redux author suggested not to use catch this way since it may catch other rejected promisses
acutally he just mentiones diplaying unwanted error message to the user
so possibly it will not swallow it if next catch exists
seems like a 'middle' catch needs to throw again for next one to catch it
elf Pavlik
@elf-pavlik
right, using reject handler will still catch promise rejected anywhere up the chain...
but catch for 404 should check error code
if(error.code === 404) {
// handle case and return Promise.resolve()
} else {
  return Promise.reject(error)
}
Daniel Friedman
@dan-f
@elf-pavlik - if you've got a promise chain in which you catch a rejection (and don't re-throw an error), that rejection has been caught and handled. a following '.catch' won't get fired
@dmitrizagidulin why are you changing the web client to not reject on 404s?
Henry Story
@bblfish
Hi all, I have been busy producing kids in the past year. https://twitter.com/bblfish/status/780445124593643521
and doing other things too of course...

I'll be giving a talk on Monday in Southampton with the following abstract

An introduction to the key components behind Prof Tim Berners Lee's work at the MIT Distributed Information Group (DIG). Why do we need distributed social networks to be secure? What avenues have we explored to do so? What remains to be done?

It would be useful to catch up a bit on what has happened here in the past 9 months or so, ...
Andrei
@deiu
Hey @bblfish, nice pictures! :)
Henry Story
@bblfish
Thanks :-)
Sarven Capadisli
@csarven
Cool photo.
My son's photos are not public but he has http://emilianc.info/#i :)
Henry Story
@bblfish
I only put a couple of photos up publicly, so that I did not have to fill in everyone's mail box when I send them pictures.
Yes. I know I should put them up on a SoLiD server protected with WebIDs and acls... I was starting to rewrite my server in June to be very efficient, but then got swamped with the babies as they were born premature, ... and to be honest also ended up reading too much of #brexit and #USElections ... So now I have my own OSX account with no social networks (not even e-mail) so that I can concentrate again.
Sarven Capadisli
@csarven
I've put some of them online with HTTP Auth.. just hand out username/password for the time being. People can check if/whenever they want.
Henry Story
@bblfish
also a solution...
Sarven Capadisli
@csarven
quick/lazy. family/relatives/friends can see something until "everything else" is sorted out :)
Henry Story
@bblfish
btw. for that it would make sense to have ACLs that are not publicly visible. Then you could describe the password in the acl.
Henry Story
@bblfish
Dmitri Zagidulin
@dmitrizagidulin
I'll add comments to it. but basically - our ACLs are already not publicly visible
read/write access to ACL resources is determined by the Control access mode
Henry Story
@bblfish
You mean they are not visible by default, or else there would be no point of having a control mode that can change the access to the acl.
Dmitri Zagidulin
@dmitrizagidulin
there isn't really a fine granularity of making the acl public-visible (but not public-writeable)
you could, theoretically, set Control = everyone, in an acl
but that just means that the first person who changes the acl can lock you out of the resource.
Dmitri Zagidulin
@dmitrizagidulin
the use case of knowing what permissions one has on a resource will be handled by returning the Allows: header on an OPTIONS or HEAD request
(there's ticket open for it)
Henry Story
@bblfish
you mean: the use case of knowing what permissions one has on a resource given how one is authenticated at the time.
Dmitri Zagidulin
@dmitrizagidulin
yeah
Henry Story
@bblfish
Making acls visible allows one to cover the case where the client wants to know how to authenticate.
Dmitri Zagidulin
@dmitrizagidulin
maybe. our security model makes the explicit design choice not to go that route, however.
in general, how to authenticate means 'which webid to use'. which further means 'know who has access to this resource'. which is not something we want to reveal
(unless the user has Control access)
Henry Story
@bblfish
I don't see that you need to have that as a design choice in SoLiD. You can have that as an implementation choice in your server or client. But I don't think you can limit usage globally like that. If folks have other requirements to yours why should they not be able to explore those?
Dmitri Zagidulin
@dmitrizagidulin
i can see a case for adding a new access mode, something like Control-Read
but we have, for the moment, decided not to go the "ACLs should have their own ACLs" route.
Henry Story
@bblfish
That's fine that you don't want to explore that route now. I believe there are good reasons to show those possibilities to the security folks at Southampton (to which I will be presenting on Monday as mentioned earlier :point_up: November 2, 2016 2:22 PM) and to other folks for consideration. It solves an important use case.
Dmitri Zagidulin
@dmitrizagidulin
noted.
what use case do you believe it solves? (without compromising security/confidentiality?)
Henry Story
@bblfish
In cases where there is no security issue in revealing that information, it enables the client to know wether he even needs to authenticate to get access, and which identity he may need to use to do so. It also allow people to advertise what the client needs to do to access the resource. Eg. if I only want friends of friends to see a resource I can declare that to be the relation required for read access which is a way to tell people that they have to become friends of my friends to be able to participate. Or the ACL could be that payment is required. It may also be that one has to be a member of a certain university. This can then also help people work out if there is a bug in the acl code on a server, and report it.