Announce : much updated Solid-File-Client


Yes, you’re right, it isn’t entirely cosmetic though it doesn’t prevent copying. From what I can see, it only applies to index.html in the pod root. I haven’t seen it with any other file in the pod root or with index.html in other containers.


Yes, wierd. I am going to investigate myself. Perhaps we can fix it together


Thats awesome thanks for this @jeffz.

I tried to use the demo but i am getting following error when i tried to upload file or copy.

SFCFetchError 403 - Make sure that the user has access to the resource


A 403 is an unauthorized origin error. Have you given your app trustedApp status in your profile? I’m changing the error message for 403 to “Make sure that the origin of your app is authorized for your pod”

If you are using the online demo, you’ll need to authorize the origin (no trailing slash)


Yes! that trailing slash made this error. It works now. Thanks! I am trying to implement a upload function preconfigured with credentials. But getting no session error.

let credentials = {
“idp” : “”,
“username” : “Manotest2”,
“password” : “password”, // OPTIONAL !!!
“base” : “”,
“test” : “/public/fitness/”
const auth = require(‘solid-auth-cli’);
const FC = require(‘solid-file-client’);
const fc = new FC( auth );
let podfolder = “”;
let local = “/data/web/blck/node/solidblcn/solidbcn/temp/file”;

console.log(“Initialising solid login”);
let session = await auth.currentSession()
if (!session) { session = await auth.login(credentials) }
console.log(Logged in as ${session.webId}.)
try {
await auth.login()
console.log(“actually trying to copy now”);
await fc.copyFile( local, podfolder )
catch(err) {


@Leoudayan which version of solid-auth-cli and solid-file-client have you installed? Ensure to use the latest ones.


Looks like you login twice the second time without credentials


@aveltens i am uing 2.4.1 latest version of solid auth client and 1.0.1 version of solid file client.

@jeffz even after removing the auth.login part, i am getting the same error. Following is the full log.

(node:879) UnhandledPromiseRejectionWarning: Error: No session!
at Object.currentSession (/data/web/blc/node_modules/solid-auth-cli/src/index.js:58:18)
at Object.exports.upload (/data/web/blc/node/solidblcn/solidbcn/models/exp1.js:77:28)
at exports.upload (/data/web/blc/node/solidblcn/solidbcn/controllers/exp1controller.js:15:16)
at Layer.handle [as handle_request] (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/layer.js:95:5)
at next (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/route.js:137:13)
at Route.dispatch (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/route.js:112:3)
at Layer.handle [as handle_request] (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/layer.js:95:5)
at /data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/index.js:281:22
at Function.process_params (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/index.js:335:12)
at next (/data/web/blc/node/solidblcn/solidbcn/node_modules/express/lib/router/index.js:275:10)
(node:879) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:879) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

One odd thing i am noticing is that i am getting the following warning near the solid-auth-cli and solid-file-client declaration

Could not find a declaration file for module ‘solid-auth-cli’. ‘/Volumes/’ implicitly has an ‘any’ type.
Try npm install @types/solid-auth-cli if it exists or add a new declaration (.d.ts) file containing `declare module ‘solid-auth-cli’;


Sorry, I meant solid-auth-cli


Ah yes!!! i didnt realise that solid-auth-cli and solid-auth-client are different. It worked now!! Once again thanks a lot @jeffz for creating this and thanks both for helping me to fix the issue @aveltens.


@aveltens - @bourgeoa found the issue with your index.html error - an NSS bug. Apparently NSS doesn’t send a content-type for index.html in the pod root and Solid-File-Client was erroring when it tried to read its headers for purposes of copying linked files. We’ll trap the error on our end better though, it shouldn’t interfere with copying.


Ah, thats great Jeff! Did you file a NSS bug already? Thanks a lot for all your efforts


Hi @jeff, I cannot reproduce this.

curl -I
curl -I

both return Content-Type: text/html; charset=UTF-8

What lead you to the assumption?

The fun(?) thing is: actually does not return the actual index.html file I stored at the Pod root, but the “Solid Data Browser” page :confused:


I mis-wrote, it returns a content-type, but not a link header. For example, this returns null:

const auth     = require('solid-auth-cli')
const podIndex = ""

    auth.fetch( podIndex ).then( response =>
        console.log( response.headers.get("link") )


Ah yes, I see. I think this is acutallly related to the fact, that an explicit request of index.html returns the Data browser page and not the actual resource.

I found an issue regarding that behaviour


The pod root index.html is an edge case from about three different angles. But we’re fixing Solid-File-Client so that the error you reported is only triggered if you are also trying to copy linked resources.


Cool :+1: but copying linked resources is the default, isn’t it? Should it not work even without a Link header? The resource just doesn’t have linked resources in that case?


LOL. Take a look at the lengthy conversation on this issue that Alain, Otto, and I have been having about this exact question. In the end we decided to only error in the case where there is an index.html.acl in the source but no .acl link in the target’s header and the user use the default withAcl=true.


That sounds reasonable. :slightly_smiling_face:


Implemented in 1.0.2, now on npm. It should no longer show an error in your situation. Thanks for your ongoing help.