Oolite Website Domain & Fixing the Expansions Manager

[timer]

Mind the difference:
https://addons.oolite.space/api/1.0/overview
https://addons.oolite.space/api/1.0/overview/

yep - it maybe a problem... url without slash - "give me this file", url with trailing slash is mean "show index file of directory"

What is the default option in the config file? If second - it is problem :(

Found "Page Rules" in CloudFlare, set rule:

Code: Select all

addons.oolite.space/api/1.0/overview/
Forwarding URL
(Status Code: 301 - Permanent Redirect, Url: http://addons.oolite.space/api/1.0/overview)

@hiran, It is must help! (in theory...)

[hiran]

Mind the difference:
https://addons.oolite.space/api/1.0/overview
https://addons.oolite.space/api/1.0/overview/

yep - it maybe a problem... url without slash - "give me this file", url with trailing slash is mean "show index file of directory"

What is the default option in the config file? If second - it is problem

Found "Page Rules" in CloudFlare, set rule:

Code: Select all

addons.oolite.space/api/1.0/overview/
Forwarding URL
(Status Code: 301 - Permanent Redirect, Url: http://addons.oolite.space/api/1.0/overview)

@hiran, It is must help! (in theory...)

The redirect is not necessarily the solution.
I cannot tell how Oolite downloads the data. But my OoliteStarter directly ecpects the result - it does not follow a redirect.

While I can add the redirect feature or simply the new URL we will invalidate all the clients that have been installed so far. Not a good idea.

Please keep the URL as it used to be.

[timer]

The redirect is not necessarily the solution.
I cannot tell how Oolite downloads the data. But my OoliteStarter directly ecpects the result - it does not follow a redirect.

While I can add the redirect feature or simply the new URL we will invalidate all the clients that have been installed so far. Not a good idea.

Please keep the URL as it used to be.

well... manifest file moved as overview/index.html, now it must working as u expect - opening directory url overview/ - will send content of index file (thanks to GitHub Pages - it support index files).

redirect swaped, now
overview >> 301 redirect >> overview/

But in general, I consider it incorrect to use the directory address to obtain data instead of the address of a specific file.
It will be difficult to change/fix this.

PS ingame manager correctly processing redirects.

[hiran]

well... manifest file moved as overview/index.html, now it must working as u expect - opening directory url overview/ - will send content of index file (thanks to GitHub Pages - it support index files).

redirect swaped, now
overview >> 301 redirect >> overview/

Thank you. Yes, I can see it works as before now.

But in general, I consider it incorrect to use the directory address to obtain data instead of the address of a specific file.
It will be difficult to change/fix this.

PS ingame manager correctly processing redirects.

The design of the API may have issues. But it already happened, it has been there for years and there are clients out there that rely on it.
So I totally agree with you: It is difficult to change/fix this. Maybe it is easier to simply accept that flaw. AFAIK it is the only API function we have.

But if we want to change it, we will have to prepare the change better than it was done this time.
See https://bb.oolite.space/viewtopic.php?p=291143#p291143

[timer]

The design of the API may have issues. But it already happened, it has been there for years and there are clients out there that rely on it.
So I totally agree with you: It is difficult to change/fix this. Maybe it is easier to simply accept that flaw. AFAIK it is the only API function we have.

Yep, it is our legacy, but...
in source file:

Code: Select all

/*static NSString * const kOOOXZDataURL = @"http://addons.oolite.org/api/1.0/overview";*/
static NSString * const kOOOXZDataURL = @"http://addons.oolite.space/api/1.0/overview";

so... in origin we have exactly file url - not directory?

This url give us 404 http://addons.oolite.org/api/1.0/overview/.
But http://addons.oolite.org/api/1.0/overview is downloading...
(Of course an entry in the hosts file is required for this checks)

Nginx on my VPS has special condition for processing overview/ without redirect.
Therefore, when the file was sent through my server, it accepted both URLs equally.
I don’t think that we can setup this on GitHub :(

Now we changed origin manifest url???

But if we want to change it, we will have to prepare the change better than it was done this time.
See https://bb.oolite.space/viewtopic.php?p=291143#p291143

IMHO this issue (bad utf symbol) is not related to main manifest url changes.
https://bb.oolite.space/viewtopic.php?p=291177#p291177

[Cholmondely]

I am sitting here, reading a conversation between a German and a Russian.

That conversation is in English. I can actually understand each word individually, but have no idea what any complete sentence actually says.

Not a complaint. Not a demand to understand. Or to be included. Just rather amazed!

[timer]

I am sitting here, reading a conversation between a German and a Russian.

That conversation is in English. I can actually understand each word individually, but have no idea what any complete sentence actually says.

Not a complaint. Not a demand to understand. Or to be included. Just rather amazed!

Oh, I hope @hiran will understand me

[hiran]

Yep, it is our legacy, but...
in source file:

Code: Select all

/*static NSString * const kOOOXZDataURL = @"http://addons.oolite.org/api/1.0/overview";*/
static NSString * const kOOOXZDataURL = @"http://addons.oolite.space/api/1.0/overview";

so... in origin we have exactly file url - not directory?

This url give us 404 http://addons.oolite.org/api/1.0/overview/.
But http://addons.oolite.org/api/1.0/overview is downloading...
(Of course an entry in the hosts file is required for this checks)

Nginx on my VPS has special condition for processing overview/ without redirect.
Therefore, when the file was sent through my server, it accepted both URLs equally.
I don’t think that we can setup this on GitHub

Now we changed origin manifest url???

I am totally surprised myself. Since when did this happen? Looking at the history of that code line I see

Code: Select all

-static NSString * const kOOOXZDataURL = @"http://addons.oolite.org/api/1.0/overview";
+/* switching (temporarily maybe) to oolite.space - Nikos 20230507 */
+/*static NSString * const kOOOXZDataURL = @"http://addons.oolite.org/api/1.0/overview";*/
+static NSString * const kOOOXZDataURL = @"http://addons.oolite.space/api/1.0/overview";

which essentially means we did not have the trailing slash before, we did not have it after the domain change. I am really wondering where I got the other URL from. If I remember correctly long ago I was running strace to find out where addons might be coming from...
The result I had at that time went into OoliteAddonScanner, and if you dig the history it's been there since the initial commit.

But if we want to change it, we will have to prepare the change better than it was done this time.
See https://bb.oolite.space/viewtopic.php?p=291143#p291143

IMHO this issue (bad utf symbol) is not related to main manifest url changes.
https://bb.oolite.space/viewtopic.php?p=291177#p291177

Yes, there are two different changes:
- One is the API - I asked you to keep the existing pattern and you reverted the change. We'd have to plan such a change better in the future so there is a migration path for the clients out there. As a first I added redirect support to OoliteStarter. It is available in the latest version 0.1.20 - it would take some time for the user base to move.
- The other one is the file's content, which changed magically. I call it that way because noone of us seemed to be involved, yet it happened. My guess is that it happened on the end that we are not managing, and by bringing that into our vicinity I believe you are doing a great job.

Actually you say that the files would be pushed into the github repository. I have not yet noticed any commit. Where would that get visible?

[hiran]

I am sitting here, reading a conversation between a German and a Russian.

That conversation is in English. I can actually understand each word individually, but have no idea what any complete sentence actually says.

Not a complaint. Not a demand to understand. Or to be included. Just rather amazed!

Oh, I hope @hiran will understand me

The fun part is: We are not really technical this time. Should we switch to HTTP status codes, REST API design patterns or character encoding and escaping?
After all the encoding/escaping part is the one causing problems, isn't it? How are you doing that translation right now?

[timer]

Actually you say that the files would be pushed into the github repository. I have not yet noticed any commit. Where would that get visible?

see branch only-media! GitHub Pages now use subdomain addons.oolite.space

file here https://github.com/OoliteProject/oolite ... 0/overview
named index.html (I explained why earlier)

before that, the file was named overview and placed in /api/1.0/

Deploy history
https://github.com/OoliteProject/oolite-web/actions

All commits by oo-acc-cf is done by my cron-script (on VPS) via GitHub API.
My server every 10 min download file from origin server and check md5sum, if it changed - file will upload to GitHub via API. The file is also converted into json and uploaded to GitHub via API (as /data/oxp.json). Right now my server doesn't do anything else other than this. And this is need only while we use old site manifest editor.

And now http://addons.oolite.space/api/1.0/overview/ is pointed exactly on
https://github.com/OoliteProject/oolite ... index.html

At this moment http://addons.oolite.space/api/1.0/overview is redirect to http://addons.oolite.space/api/1.0/overview/ (this is doing by CloudFlare Redirect Rules)
As I understud - we can change back redirect, some time later? )

[timer]

I seen automatic uploaded changes to GitHub
Xenon UI v3.6.1 from @phkb
it works! )

[phkb]

Am I correct in assuming the old manifest DB is now no longer in use?

[timer]

Am I correct in assuming the old manifest DB is now no longer in use?

No!
We now use old site as DB+Manifest Editor!

My server periodically download manifests file from old server and (if it changed) - upload it to GitHub.
"Ingame" manager and my site use data from GitHub now.

I finished development of converter from MySQL DB dump to CloudFlare database (D1) with new tables structure.

So next step - create new manifest editor on new site - code and DB on CloudFalre, only after this we can completely stop using the old server and my VPS.

@hiran is right - I should try to draw a diagram - how it works, otherwise it's hard for me to explain

[timer]

I have a problem :(
I thought that I could somehow save the logins/passwords of database users. But the password hash is “salted” - and this “salt” is only in the PHP-config of the old server... Now I don’t know how to organize access rights to existing manifests in the database... we can issue new passwords to those who are on the forum and who we know, but what about those who are inactive...
Are we sure we don't have anyone with access to the server?

[phkb]

No!
We now use old site as DB+Manifest Editor!

My server periodically download manifests file from old server and (if it changed) - upload it to GitHub.

Not sure what this means, then:

This is the Xenon UI DB entry - not the version number - 3.6.


And here is what's showing on the OXP page. Note the version number: 3.6.1.

So, when I updated the entry via the web form, it doesn't look like the data has flowed back to the DB. I've made other changes to the DB (moved ownership of an OXP) which haven't been reflected on the web form.