Plugin servers / getting plugins to a system

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin servers / getting plugins to a system
« Reply #45, on October 20th, 2011, 11:01 PM »
Hmm, yeah, which is impractical and a PITA (and what was there only works if allow_url_fopen is set)

In which case, the only solution is ugly and rather costly in memory terms (but I can put a test to try and prevent it dying due to being out of memory), which is to call imagecreatefromstring - since we have the string handy - and build an image out of it for imagesx and imagesy. That seems familiar, SMF may even have done it but with all the code and staring at hex dumps of files in the middle I may well have forgotten about it :/

I didn't even realise until yesterday that fetch_web_data not only supports FTP but also arbitrary HTTP POST content. (Of course Class-WebGet *also* supports those things, which I suspect is not so well realised in the first case)


Getting back to the original topic, I realised a problem that I don't know how to deal with: authentication. I originally figured I'd send the username and password to the server as part of the request, but I realised that if the destination wasn't open to guests, it'd never reach its destination at all. So either I have to put in the requirement that a destination forum/plugin server be open to guests (since I'm looking at making it a plugin itself), or have it do an authentication and login as the first request, send back the cookie (and have that stored somewhere temporarily), then resend the actual request for updates complete with cookie.

Hmmm. It seems so much easier to make the plugin server be a separate file that can authenticate on its own without having to create a user session etc. Maybe I should do that (though that has its own interesting side effects, and I'd rather make it an action)
Re: Plugin servers / getting plugins to a system
« Reply #46, on October 21st, 2011, 12:48 AM »
Specifically on the last part, I'd appreciate feedback from people who might build paid repositories of plugins: would having 'allow guests to browse the forum' be a huge problem? I'd personally assume not, because of having an area outside the paywall, for pre-order questions and any freebies you offer too.

(This assumes that there will be external sites, pretty much needed for paid resources because there is no way I want wedge.org to have to cope with the legal liability issues that arise out of hosting the plugins like a store)

Reason I ask is that I can safely get round the above issues and avoid having to create a separate file etc, and just have it as a regular plugin through the actions facility.


(I am also interested in providing a similar framework for themes, and will likely base a lot of it off the core from the plugin manager but that's another day entirely.)
Re: Plugin servers / getting plugins to a system
« Reply #47, on October 21st, 2011, 03:10 PM »
I'm guessing that the above limitation isn't really an issue... after all, as discussed elsewhere today, the best promotion of paid work is free work, and I really can't see having totally locked off repos in any meaningful fashion.


Going back to earlier in this discussion, I've been trying to figure out how tar.gz support should theoretically work if it's going to be provided for. I see two major issues that need resolution.

Firstly, detection of (probably) validity of package. With .zip packages, there's a central directory of what's in it, which is accessible without unpacking the file directly, so we can test for plugin-info.xml quickly and relatively easily. (Even if it's in a subfolder, as /plugin/plugin-info.xml instead of /plugin-info.xml)

No such luck with tar.gz; it's not one file format, it's two, which means we have to unpack it physically as a file first to unpack it from gz format into tar, and even then we can't just arbitrarily dive into a tar. It is almost certainly nested (SMF is aware of this fact and has specific recursive code to cope with it) and the way it's done makes it harder to figure out if the plugin is valid up front or not.


Secondly, unpacking. Because of way zip files can be accessed, it's possible to do what we need: create a new folder and unpack things into that. Untarring is a lot more complex and will almost certainly require not only unpacking, but unpacking and then shunting files around after because of the inherent way it handles nested folders.


I'm hoping SMF's tar.gz unpacker might be salvageable but you never know. There's going to have to be some rewriting going on to support the remote file addressing stuff... maybe it's doable, we'll see. It's likely going to be less efficient than SMF's was, given the changes in how things are done but it should be more reliable in the long run.
Re: Plugin servers / getting plugins to a system
« Reply #48, on October 21st, 2011, 05:02 PM »
After spending the last two hours trying to figure out the mechanics of how this would have to work, I have reached only one conclusion.

If people want to use the upload/download facilities, safe mode has to be off, and I think I'm just going to block out the entire area if safe mode is on, because there's so many ways it can screw up operations.

Note that it still doesn't solve chmod issues, even with safe mode off, but that it causes a great number of other issues on top of that.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin servers / getting plugins to a system
« Reply #50, on October 21st, 2011, 09:14 PM »
Yeah, that's why I'm going to be disabling access with safe mode. If you really want to use plugins in safe mode, unpack them to your PC and upload via FTP.

chmod on the other hand is still the greatest PITA it has ever been.