Support forums : The Future

3rd party plugins and templates

The future of this project but not in a "I want a pony" sort of way. This is all about everything meta about Quam Plures. The general direction, the support tools, stuff like that.

Moderator: Dracones

Re: 3rd party plugins and templates

Postby EdB » Sun Sep 18, 2011 11:38 pm

I still don't see the traffic hit so I'll try to explain where I'm at differently than before.

Someone visits QP and sees that I finally updated my creative commons plugin. When I told QP about it the file was 73K created on 2011-10-09. QP will do one simple task, assuming it hasn't done it lately: hit my server and get the file size, the datestamp, and maybe do some sort of checksum hash if it can. In other words QP gets from my site something like this:
"74256, 2011-10-09 01:14:54, 8d06b3fcc47ee998eb4ef555333a29fc67be8636". That's it.

QP then compares those 2 or 3 bits of information to what it already knows, and decides to keep the post as-is or deprecate it.

So where is the bandwidth problem?

Personally where I'm at is I don't know if a file can access that type of info from another server. I can do it on my own server yeah sure, but on another server? That is where we might need a plugin author to put a file in the directory where they store their zips. We call that file, it gets the info and returns it. That of course means we have to trust them not to fuck with the file so it goes round and round and round.
User avatar
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: 3rd party plugins and templates

Postby leeturner » Mon Sep 19, 2011 11:05 am

EdB wrote:Personally you'd never see plugins from me if that was the rule. I'd still do plugins, but I just wouldn't bother telling QP I have them. I'm a control freak is the thing, but for sure I want the traffic. I want the feedback and discussion in one tidy little place, and I want that place to be where I benefit from the increased traffic.

@Lee perhaps one day when things get not busy we can work on this? We build a plugin together that we test by hitting each other's path. The less we expect of each other the better, and we can monitor for traffic and so forth.

The traffic is quite important when a plugin author is taking the time to write the plugins. They can be a source of revenue in terms of additional services etc so we wouldn't want to take that away from plugin authors.

I'd be happy to play with a plugin that checks file checksums etc but I am not sure it is worth it at this stage. To benefit from increased traffic, the QP site will need to link to the individual posts on the plugin author site like this one - (not the individual files) so people wanting to download the random youtube plugin visit Ed's site and Ed can offer his whole range of services to them. If the QP site just links directly to the files the plugin authors site is just being used as a file store, we are leaching bandwidth from them and they are not seeing the benefit of the traffic.

You could then follow on to say that to be listed on the QP site they must give us the direct link to their plugin and we will feed that into our checker but won't display it on the QP site. We could then check the file and make sure it was the correct one to deprecate the post if need be. However, once the visitor hits the plugin author's site we are out of control so they could easily leave the file that the QP site is checking and let the visitors download a totally different plugin that does evil nasty things to their blogs.

Like I said, not sure it is worth the investment in time.

User avatar
Posts: 730
Joined: Fri Dec 11, 2009 11:55 am
Location: Brighton, UK

Re: 3rd party plugins and templates

Postby Tblue » Mon Sep 19, 2011 11:10 am

EdB wrote:So where is the bandwidth problem?

The problem is that in order to calculate the checksum, you need to analyze the whole file (and thus download it). Timestamp and size can be obtained without downloading the file, though (in most cases).

So, we could drop the checksum and use only the file size and a timestamp, but I'm not sure that's enough...

EdB wrote:That is where we might need a plugin author to put a file in the directory where they store their zips. We call that file, it gets the info and returns it. That of course means we have to trust them not to fuck with the file so it goes round and round and round.

Yes, a script on the server would be the best solution, but as you said, one could modify it to return wrong information. Hm, I guess one could try to make that harder, though (forging information or altering the script). Interesting! I'll have to think about this.

Well, in the end, the easiest solution might really be to just say "Our own plugins are safe but you're on your own if you use 3rd party templates or plugins".
Posts: 340
Joined: Sat Nov 21, 2009 1:35 pm
Location: Berlin, Germany

Re: 3rd party plugins and templates

Postby EdB » Mon Sep 19, 2011 4:06 pm

@Lee: I guess I didn't state it clearly, but yes QP would be linking to the post - not the file. QP would need to know the home of the file, but would link to the post. The post would be pretty much just like our current posts, which means the long description field, but the links go to a blog post or maybe multiple posts depending on how the author handled posting about revs. Oh and spot-on regarding traffic. I absolutely want to monetize my efforts. Traffic in and of itself is not assurance of that, but not getting traffic clearly won't.

@Tblue: I wasn't sure about the checksum thing, but near as I can tell to do a scandir requires ... I forget what to be turned ON at the 3rd party site and it is something that should be turned off in a smart server. So realistically the only way to get *any* info about the 3rd party files is a file they upload for us. Fortunately the file becomes it's own security service just by doing a scandir on the path it is in.

(1) QP gives 3rd party with a random name. 3rd party gives back the path. QP checks the path and runs the file. QP gets back the results of a scandir that tells the file to report on itself (size, date, checksum). QP stores that info.

(2) 3rd party says "here is a plugin post (link) and the path to the zip (link) and the long description (text)". QP hits the randomly named file looking for (size, date, checksum) on the randomly named file AND the supplied zip file. FIRST time we also download it from that place else how can we even check to know it is a plugin and not a virus or walrus or copy of b2evolution v0.8.6 eh? Anyway QP then stores the zip's (size, date, checksum) assuming it is good by some minimum criteria.

(3) Ever after, upon hitting a page we check no more than once in 24 hours to verify the randomly named file and the plugin zip are still what we stored about them.

(1+2+3) The 3rd party and QP both need each other, so both work together. The randomly named file is a tool that allows verification of stability of product. 3rd party can't change the zip without informing QP or the post goes away. QP doesn't offer the zip but has confidence that what we're linking to is still there and still what it was.

Not a worry. Mostly replying this time to bookmark the thread for another day when something like this might be fun in my head. Right now the awesome blog creator is where I'm at.
User avatar
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona


Return to The Future

Who is online

Users browsing this forum: No registered users and 1 guest