"LRS invalid: failed to divide URL parts"

[tbuckham]

Hi

I've set this up to take a look, but when I add in a sample app (an xAPI learning object packaged as a .zip with the index.html in the root dir) it fails to launch with console logging: code: 4mesg: "LRS invalid: failed to divide URL parts"

Previously we saw this sort of error when failing to pass the LRS endpoint details correctly as a parameter - which was easy enough to resolve. However, as the launcher is handling the passing of the endpoint details I'm not immediately clear on how to troubleshoot the issue.

my config.json has https://www.xxxxxxxxxx/data/xAPI/ as the LRS URL (taken direct from my LRS, so seems unlikely to have been added incorrectly).

I'm adding in a key and secret for the LRS_username and LRS_password - presume that's correct?

Otherwise the only other thing I noticed is that there is scope to include LRS details in your user profile in the launcher app - however adding the same details (As they are in config.json) didn't work either...

Any thoughts/help welcome :)

[vbhayden]

Morning tbuckham, there was another person having a similar issue with their url not being fully qualified. Is this behavior similar to what you're experiencing?

In app.min.js, when parsing the endpoint of a story published in Storyline 3, the line: this.endpoint.toLowerCase.match(), returns null, so we get LRS invalid: failed to divide URL parts

https://community.articulate.com/discussions/articulate-storyline/lrs-invalid-failed-to-divide-url-parts

Another person had the issue when providing relative paths,

http://somedomain/modules/somemodule?endpoint=../../xapi

Which was also resolved with an absolute url.

https://github.com/RusticiSoftware/TinCanJS/issues/85

[tbuckham]

Hi there

Thanks for your quick reply, much appreciated. Given that the launcher is handling the serving of the endpoint URL (i.e. we're not just including it directly as a parameter), how would we change things so we were not using relative paths?

For example, when using this launcher it seems you can either include an LRS endpoint in the config.json file, or via your account details:

config.json.sample:

"LRS_Url": "https://lrs.adlnet.gov/xAPI/",   //the LRS endpoint to which statements should be saved. The user profile can override this
"LRS_Username": "",  //the username of the authority to use. The user profile can override this.
"LRS_Password": "", //the password to use. The user profile can override this
"host" :"http://localhost:3000/", //this information is used in the context activities. You should set this to the public facing URL of the launch server

Or here:

At no point do you enter the LRS endpoint in anything other than an absolute URL - so what part of the launcher codebase might be implementing a relative path?

Tom

[vbhayden]

I'm not sure what part of the codebase is even sending out that "LRS invalid: failed to divide URL parts" message. The closest I can find is the old tincan js but even that old regex bit passes with op's redacted endpoint: https://jsfiddle.net/gyg9y8hb/

[tbuckham]

Hi - https://www.xxxxxxxxxx/data/xAPI/ is not the actual endpoint, that was just an example - I can see you used it in the JSfiddle for some reason.

It seems that in the launch service, the LRS endpoint and auth details are not being passed correctly to the content (I presume). In terms of setting up the launcher app can you advise with examples on how the endpoint and basic auth details need to be included, so they can be passed by the launcher? Any other sample config.json files to reference perhaps?

e.g. there is reference to the LRS username and LRS password - my assumption is that it's the key and secret? It's hard to pinpoint what the issue is as the launcher is handling all these parameters.

Tom

[vbhayden]

Yeah, I'm pretty sure a string of x's would not be a typical url. :-) Was just to confirm that the regex did indeed work even with pretty silly endpoints.

Super silly question, but have you tried giving the LRS username / password for those arguments? Xapi sends a base 64 concatenation of the user's username/password as an http header when sending things to the target LRS waiting at the endpoint.

-Trey

[tbuckham]

Hi Trey

When you say LRS username/password - what do you mean? I setup client credentials to use for the xAPI server so I have a key and secret which I've been using as the username/password, presuming those would be used for basic auth details. Are you suggesting some other username and password?

Can you confirm what is expected to be included in the config.json files with the launcher for those details - there's no values in the sample config file

Cheers for your help!

[vbhayden]

Which LRS are you using? If you're using the public ADL LRS (https://lrs.adlnet.gov/), then you've provided a username and password when you made your account originally (which I assume happened as you have your auth keys / secret).

[tbuckham]

I was using my own LRS for some prototyping - a Learning Locker installation. I just setup an account at adlnet to try that endpoint but it doesn't change anything unfortunately. I.e. if I point the LRS details to their public one, and use the username and password for the account you still get the same error with our xAPI content (failed to divide URL parts).

Alternatively when I try the 'static/staticContentDemo/demo.html' page (I was checking to see the behaviour of other sample content as a break from troubleshooting this main issue) then there's a 401 error posting back to the proxy LRS (i.e. in my case it's http://localhost:3000/launch/2aa3e6b9-c3c1-cfef-b046-abe7ae1d5ca7/xAPI/statements). This is using account details setup via the prototype, so I'm uncertain as to why a registered user would be unauthorised from posting to the proxy LRS endpoint...

[FlorianTolk]

This may be a silly question, but are you using the latest of version of this project? The only time we can find this error message is with a very old old version.