Auth problems running in GitLab Pages

#1

I’m having authentication problems trouble running my single-file wiki inside GitLab Enterprise Edition Pages. I will check with the infrastructure folks here at GigantiCorp, but as it took them a year to get GL Pages working, I’m not counting on quick help.

I’m trying to use git and Node to track changes made to the content but then deploy a read-only mode single page to all the users (this is software documentation, and I want to restrict authors.)

I’m able to build my Node wiki into a standalone HTML version with

tiddlywiki . --output public --render '$:/core/save/all' index.html 'text/plain'

from inside an NPM package.json > scripts step. I can then open the generated file from the file system or from a simple local HTTP server. But when I try to open it from inside the GitLab pages, I get this error every few seconds:

Network Error

It looks like the connection to the server has been lost. This may indicate a problem with your network connection. Please attempt to restore network connectivity before continuing.

Any unsaved changes will be automatically synchronised when connectivity is restored .

Everything is there, working fine except for that error. But that one of course makes it all pretty useless.

This does not happen for a plain HTML file published alongside it for testing. In the Network console for the plain page, I see:

GET https:/<myaccount>.<corp-gitlab>/<project>/foobar.html
304

GET https://<myaccount>.<corp-gitlab>/favicon.ico
302 Location: https://<gitlab-auth-server>?domain=https://<myaccount>.<corp-gitlab>&state=<base64-token>

GET  https://<gitlab-auth-server>?domain=https://<myaccount>.<corp-gitlab>&state=<base64-token>
302 Location: https://<gitlab-oauth-server>/authorize?client_id=<token>&redirect_uri=<gitlab-auth-server>&response_type=code&state=<base64-token>&scope=api

GET https://<gitlab-oauth-server>/authorize?client_id=<token>&redirect_uri=<gitlab-auth-server>&response_type=code&state=<base64-token>&scope=api
200 OK

But when I try to load my wiki, I get

GET https://<myaccount>.<corp-gitlab>/<project>/index.html
304

GET https//<myaccount>.<corp-gitlab>/<project>/status
302 Location: https://<gitlab-auth-server>?domain=https://<myaccount>.<corp-gitlab>&state=<base64-token>

OPTIONS https://<myaccount>.<corp-gitlab>/<project>/index.html
200 Body: <html-wiki>

HEAD https://<myaccount>.<corp-gitlab>/<project>/index.html
200 (from disk cache)

data:images/png;base64,<image-from-default-tiddler>

GET https://<gitlab-auth-server>?domain=https://<myaccount>.<corp-gitlab>&state=<base64-token>
302: https://<gitlab-oauth-server>/authorize?client_id=<token>&redirect_uri=<gitlab-auth-server>&response_type=code&state=<base64-token>&scope=api

GET https://<gitlab-oauth-server>/authorize?client_id=<token>&redirect_uri=<gitlab-auth-server>&response_type=code&state=<base64-token>&scope=api
302 Location: https://<corp-gitlab>/users/sign_in

GET https://<myaccount>.<corp-gitlab>/recipes/undefined/tiddlers.json?filter=[all[tiddlers]] -[[$:/isEncrypted]] -[prefix[$:/temp/]] -[prefix[$:/status/]] -[[$:/boot/boot.js]] -[[$:/boot/bootprefix.js]] -[[$:/library/sjcl.js]] -[[$:/core]]'

GET https://<gitlab-auth-server>?domain=https://<myaccount>.<corp-gitlab>&state=<base64-token>
302: https://<gitlab-oauth-server>/authorize?client_id=<token>&redirect_uri=<gitlab-auth-server>&response_type=code&state=<base64-token>&scope=api

GET https://<gitlab-oauth-server>/authorize?client_id=<token>&redirect_uri=<gitlab-auth-server>&response_type=code&state=<base64-token>&scope=api
302 Location: https://<corp-gitlab>/users/sign_in

And those last three repeat over and over.

I’m especially confused by recipes/undefined. What is that coming from?

I guess from this group, I was hoping to find out if that makes any sense. I have no idea why my oauth works in one case and not another, when both are serving plain HTML.

But even if there are no ideas about that. Is there some way I can stop the server requests when I’m serving in this fashion? Again, it’s not just a matter of serving the plain HTML over HTTP; as I tested with with a local web server and localhost.

Any suggestion are welcome. If this fails, it’s not the end of the world: I’ll just end up just deploying the Node version. But if I can get this flow to work, it would probably be better for my project. And I really want to know why! :smile:

#2

I know nothing about GL, but I’ll wade in until someone that does pipes up. If you look at your generated html page, what plugins does it contain? I’m thinking it might still contain the plugins that are used for node, which might accidentally attempt to connect to GL in an unauthorized manner.

If there’s a way to deploy node TW over GL … that sounds interesting.

#3

That’s probably it. As soon as I’m back at my desk, I’ll find a way to avoid including tiddlyweb and filesystem.

Thank you.

#4

That was definitely it. For those who have similar issues, don’t try to fix it this way:

clone $:/core/save/all to $:/_myProj/core/save/most
Add to the filter

-[prefix[$:/plugins/tiddlywiki/filesystem]] -[prefix[$:/plugins/tiddlywiki/tiddlyweb]]

Replace the following build step

tiddlywiki myProj --output public --render '$:/core/save/all' index.html 'text/plain'

with this one:

tiddlywiki myProj --output public --render '$:/_myProj/core/save/most' index.html 'text/plain'

Perhaps with enough fiddling around with the filters, we could get this to work.

Instead, replace that build step with the simpler built-in option:

tiddlywiki myProj --output public --build index

D’oh.

It’s all working now, and as to this:

There is a way, and if this is not a particularly well-known process, I can write something up here (after sanitizing actual GigantiCorp data) to explain how it’s working for me. Let me know if that’s worth doing.