Federation is broken on sib-display (0.10)

changed the description

assigned to @matthieu

changed milestone to %0.10

added BUG label

added P1 label

@jbpasquier I tested you JSBin in 0.10 and 0.9 and it's not working in both cases. I see at least 2 issues:

Is the syntax of this response expected? https://api.test1.startinblox.com/sources/circles/
The second container only has an @id, I think this was not the case before. It had the structure of the first one
When logged in on test1, I have a 403 when accessing https://api.test2.startinblox.com/circles/

@matthieu On 0.9 it's always working fine on my side.

The syntax didn't changed, it's the one for distant containers.

You have a 403 because you need to login on test1 to be properly logged in on test2. Maybe this is a track for the issue, when I login to test1 (which is with 0.10 now), I'm not logged anymore on test2 as I were with 0.9.

Also, another issue here is to show https://api.test2.startinblox.com/circles/ as a valid value when it's a 403.

Also, another issue here is to show https://api.test2.startinblox.com/circles/ as a valid value when it's a 403.

I don't get what you call "a valid value" here, what should we show?

The syntax didn't changed, it's the one for distant containers.

What I was thinking is that before, as described in this issue, we had something like this:

{
  "@id": "",
  "@type": "ldp:Container",
  "ldp:contains": [
    {
      "@id": "https://api.test-nantes.happy-dev.fr/users/",
      "@type": "ldp:Container",
    },
    {
      "@id": "https://api.test-paris.happy-dev.fr/users/",
      "@type": "ldp:Container",
    }
  ]
}

I believe the federation does not work anymore if the @type property is not here, we need to fix this

I don't get what you call "a valid value" here, what should we show?

A 403 is not mean to have its own line. If I use an invalid url as a data-src I don't expect the framework to behave like it worked.

To be more explicit, when a source contains a 200 and a 403, I don't expect to get an empty entry on my list with the 403 on it. Just ignore it, maybe pop an error on console too. The current behavior mean that if I call two sources on the same federation, one is empty and one is 403, I'll not get the empty widget but an empty line with a lot of errors on console.

I believe the federation does not work anymore if the @type property is not here, we need to fix this

I never saw this on any server on any version. Distant resources always had only an id.

Here's 0.9 vs 0.10, I only changed the version on the code, I'm logged in only on test1 and I'm logged in on test2 with the same user (Magically, as it worked on 0.9)

I'm pretty sure that the only issue is that when you login with 0.10, you're not anymore logged in to other servers you contact. Don't know why though.

Ok so actually it was meant to work only with this data structure:

{
  "@id": "sources.jsonld",
  "@type": "ldp:Container",
  "ldp:contains": [
    {
      "federation": "users",
      "@id": "users-paris.jsonld",
      "@type": "ldp:Container"
    },
    {
      "federation": "users",
      "@id": "users-nantes.jsonld",
      "@type": "ldp:Container"
    }
  ],
  "@context": "https://cdn.happy-dev.fr/owl/hdcontext.jsonld"
}

But in 0.9, even if it was not designed for this, we had a mechanism which made it work without the @type property.

I'll publish a fix for this

mentioned in commit 693f15cc

mentioned in merge request !384 (merged)

mentioned in commit 37007b73

closed via merge request !384 (merged)

Federation is broken on sib-display (0.10)

Designs

Child items ...

Activity