Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 25 16:26
    jeff-zucker commented #232
  • Feb 25 08:17
    WhyINeedToFillUsername commented #232
  • Feb 25 01:40
    jeff-zucker commented #232
  • Feb 25 01:39
    jeff-zucker commented #232
  • Feb 25 01:39
    jeff-zucker commented #232
  • Feb 24 19:19
    WhyINeedToFillUsername opened #232
  • Feb 05 14:54
    csarven transferred #4
  • Jan 14 13:58

    RubenVerborgh on websockets-version-format

    (compare)

  • Jan 14 13:58

    RubenVerborgh on master

    Remove slash from version numbe… Drop alpha from version number.… Replace warning by explanation.… and 1 more (compare)

  • Jan 14 13:58
    RubenVerborgh closed #230
  • Jan 14 13:58
    RubenVerborgh closed #221
  • Jan 13 20:37
    WhyINeedToFillUsername commented #230
  • Jan 04 02:47
    ewingson commented #221
  • Jan 01 22:15
    scenaristeur commented #221
  • Jan 01 22:15
    scenaristeur commented #221
  • Jan 01 22:10
    scenaristeur commented #221
  • Jan 01 20:05
    bourgeoa commented #221
  • Jan 01 16:48
    scenaristeur commented #221
  • Dec 09 2020 16:16
    TallTed commented #209
  • Dec 09 2020 15:54
    michielbdejong closed #193
Ruben Verborgh
@RubenVerborgh
it says "write your server in this very specific manner following this existing spec"
and CORS is just an easy one, where we're more or less saying "just use it", except that it takes multiple paragraphs for something like CORS already
Tim Berners-Lee
@timbl
The current specification says “cors is very big thing getting in your way— use it right” but does not formally define the solid protocol unless I have missed it
The spec needs to (a) define the protocol and (b) describe the invariant properties of the system when the protocol is followed
Martynas Jusevicius
@namedgraph_twitter
i think there's many more things that should be "formally defined"
Mitzi László
@Mitzi-Laszlo
It would be helpful to have this conversation in an issue so we can easily refer back to it. solid/specification#29.
Mitzi László
@Mitzi-Laszlo
@/all please have a look at solid/process#100
Ruben Verborgh
@RubenVerborgh
@timbl That is indeed the case for solid/solid-spec v0.8
However, we are writing a spec document with normative language, and there is a first PR for CORS, which defines it very precisely: solid/specification#13
Should cover your (a), and think also (b) but not fully sure what you mean
boulderwebdev
@boulderwebdev
If solid-auth-client supported a user-defined header for authorization, such as X-Solid-Authentication, is this compatible with the spec?
Dmitri Zagidulin
@dmitrizagidulin
@boulderwebdev in general, you can add whatever header you like. (tho there are CORS issues, you may need to modify the server)
@boulderwebdev what will you be using that header for?
boulderwebdev
@boulderwebdev
@dmitrizagidulin oh I want to replace the standard authorization header's name because it is not compatible with nginx's basic auth module
Either the browser or nginx is writing over solid-auth-client's Authorization header while I talk to my server (right now I want to hide the server from public view by protecting it with http's basic authentication)
Dmitri Zagidulin
@dmitrizagidulin
@boulderwebdev interesting. i’m not sure that’d be an easy lift.
you could turn off account creation, and have a blank front page, and the rest of the site is protected..
boulderwebdev
@boulderwebdev
@dmitrizagidulin I was trying to protect both that and my SPA, but I'm having problems setting up a custom repo which has the changes I want
meaning, when I change the solid-auth-client to git+https://github.com/user/my-solid-auth.git, npm is getting into a tizzy about permissions issues
Dmitri Zagidulin
@dmitrizagidulin
@boulderwebdev so, npm has a shorthand for that
if before your package.json was “solid-auth-client”: “^2.0.0”
you can switch it to
“solid-auth-client”: “user/my-solid-auth”
and it’ll work
boulderwebdev
@boulderwebdev
@dmitrizagidulin hmm I'm still running into issues building my app. I put in solid/solid-auth-client, and that works correctly
but if you go ahead and clone the repository, delete the .git folder, create your own repo and set it up in the cloned folder, push it up to your new repo, then running npm i complains about building this repo
I can DM you a full stacktrace if you'd like
Dmitri Zagidulin
@dmitrizagidulin
why not just put your cloned repo in the npm file directly? no need to delete .git etc
for example, if Bob clones that repo, he can just put ‘bob/solid-auth-client’ in the package json
boulderwebdev
@boulderwebdev
ohhh that's what I mean
I was telling you my steps for creating my-user/my-solid-auth
Dmitri Zagidulin
@dmitrizagidulin
oh i see.
still tho, you can just fork and rename the repo on github
there’s almost never a need to delete .git
and, sure, you can dm me the error
boulderwebdev
@boulderwebdev
:thumbsup: that's way easier
A_A
@Otto-AA
Hey there, I would like to continue working on two javascript libraries for working with acl permissions but would need some clarification of the spec:
Can multiple acl:accessTo values be used in the same document and/or authorization? (solid/web-access-control-spec#68)
Does the value of acl:defaultchange its meaning? (solid/web-access-control-spec#63)
Michiel de Jong
@michielbdejong
@Otto-AA they can live alongside each other and do not influence each other
Martynas Jusevicius
@namedgraph_twitter
@Otto-AA this is the authoritative version of the W3C ACL ontology: https://www.w3.org/wiki/WebAccessControl
definitely can use multiple acl:accessTo, it's RDF :)
A_A
@Otto-AA
@michielbdejong I am not sure if I expressed myself clear enough. The questions I raised are two independent questions and not related to each other. Or did I misunderstood your answer?
@namedgraph_twitter Thanks for linking me this version. From what the wiki says it is possible to use multiple acl:accessTo's too. Even though the solid-spec explicitly states that it differs from the wiki version, I think it is safe to go with this definition.
Dmitri Zagidulin
@dmitrizagidulin
@namedgraph_twitter @Otto-AA
re authoritative version of the W3C ontology - that is not quite correct. Solid uses its own specification, the authoritative spec being https://github.com/solid/web-access-control-spec
not the wiki
Martynas Jusevicius
@namedgraph_twitter
@dmitrizagidulin and that's exactly the problem
it hijacks the same namespace
and adds its own semantics
Dmitri Zagidulin
@dmitrizagidulin
specs... aren't kept on a Wiki. that is not a document or tool that makes it possible to achieve consensus, version the spec, etc. And that Wiki is not attached to any working group or other standards body. The Solid project has no jurisdiction over it
I think the solid's WAC spec is very clear that this is a solid-specific version of the spec