Add-on Install & Upgrade

Add-on Install & Upgrade 1.4.3

No permission to download
Hi there

Really sorry.

There's a fix for this posted by Mr.Goodie2Shoes in this thread.

On phone at the moment so if you can't find it then I will post it later.
 
I think the guy wants to know if he can install add ons hosted on other Resource Managers.

The answer is no, not at this time.
 
I think the guy wants to know if he can install add ons hosted on other Resource Managers.

The answer is no, not at this time.

yes thats what i want

cuz i see the source file its just change the domain name and change path name for the RM to get it work for another RM forum , but i didn`t find way of make it 2 -_- as iam not php programer ;p

but thanks any way =) love ur work
 
There are a few addons that do not have an upload folder so the addon XML file gets copied to the forum root as well. There are also some addons that do have an upload folder, but place their XML file inside the upload folder for some reason. :p I end up having to delete them manually. Do you think it's a good idea to filter out XML files with an "addon-" prefix?
Maybe you missed this post.

Also relating to copying files I think you may need to create some sort of blacklist, or whitelist in addition to the XML addon files. I installed the Custom Widget System not knowing there was a .git folder included in that addon. When I ran a git diff I thought what the heck, why is it showing files from this addon in my git status. I thought "oh crap" and looked in the zip and saw the .git folder and quickly realised that it overwrote my own git project. That really made me sweat.

Luckily I had hourly backups running and was able to recover my project, phew... The crazy thing is that a couple weeks ago I noticed that my backups did not include my git folders, so only for the last week or two were they included, and I'm really lucky I did that just before this incident. This is one of the rare cases where it would have been better to test an addon on a production site rather than development (didn't use git on my production). :p Hopefully these files can be filtered out from copying in the short term. In the long term what might be nice is being able to have user defined files and folders to be ignored when copying files instead of requesting each time to block certain files that could cause issues. Regardless, I probably need to take a look at the zip before installing next time. :confused:
 
Maybe you missed this post.
Sorry.

I wrote a big post explaining a few things. But basically I will see what I can do. If there are things in an upload directory it isn't for me to decide what should or shouldn't be uploaded so I probably won't fix that. Where there isn't an upload directory (like the CWS add-on) I will probably filter certain things out or have a blacklist pre-populated with certain things.

Thanks.
 
No problem... :)

If there are things in an upload directory it isn't for me to decide what should or shouldn't be uploaded so I probably won't fix that.
Hmm, well for addons that do have upload folders, sometimes there are stuff you don't need. For example in addition to
the files already mentioned other random files I might not be interested in: .DS_Store, thumbs.db, install.txt, readme.txt, desktop.ini, etc.

The use of wild cards would be nice too:
addon-*.xml
library/ABC/*

So maybe a textarea to list a bunch of files or folders you want excluded. If later I decide I do want these files included, I could remove certain entries at will. Although I doubt much people would need this much control, I might be the only one. :p So it probably wouldn't be worthwhile to write all the extra code necessary for such minor things... but just throwing it out there.
 
Would it be possible to clean up RM links even if they look like this
Code:
http://xenforo.com/community/resources/dc-smiley-manager.1076/updates
So the Addon removes the sub tab URL part cause its possible to install something from these links, or better say it worked for me.

Another request would be the abbility to delete update links or something like that (for example for XenCarta, as it is no longer delivered through the old RM entry and the new one is more or less a link to paypal).
 
Another request would be the abbility to delete update links or something like that (for example for XenCarta, as it is no longer delivered through the old RM entry and the new one is more or less a link to paypal).
Just edit the update link and leave it blank when you save. That will stop it from being checked for updates.
 
Couple of comments ...

While I like the idea, and used the similar mod on vB for years, I'm a little concerned about the permissions issue. You have described this as a host problem, and that it works for most people, and that people should set up their permissions such that it allows this mod to work, but doesn't compromise security.

The problem is, as a previous poster pointed out, this just isn't possible, without an ftp layer. The only way to achieve this is to give the httpd user write access to (basically) the whole of XF. Which by definition is insecure. The web server can now overwrite code it can then run. This is a Bad Thing <tm>.

The only way to overcome this is to use an ftp layer, where you drive ftp sessions using configurable credentials, for a user that is not the httpd user, and has write access to XF. I'm fairly new to XF, so I haven't had time to look, but if it doesn't already provide an optional ftp layer API for uploads, it probably should! A good example of an ftp layer is in the Joomla! CMS. if XF doesn't provide this, then the only option to make this mod safe is for you to create your own.

With regards to not making decisions about not uploading certain content, in the case of things like .git or .svn folders, there is absolutely no reason for an addon upload to ever contain those, and if they do it is almost certainly by mistake, and IMHO you'd be doing people a service by not installing them. As a previous poster pointed out, the result of upload a .git folder can be nasty. And as using this addon means we uploading content manually using ftp, we are less likely to spot such fubars than when installing by hand.

As someone else suggested, a simple configurable list of regex style patterns to filter out, containing stuff people have already suggested (iOS thumbs folder, .git, etc) would be useful.

-- hugh
 
Well there's varying opinions on how secure or insecure server configurations have to be. This is why I do not provide advice on configurations. It's down to interpretation. Some people won't touch it, others who are experienced Linux web server admins haven't got an issue with it because either the overall risk is low or being mitigated elsewhere.

If there is anything I can reasonably do to improve security, I will. But until then if you are unsure, or do not understand the implications (if there are any) then do not install the add on. Please consult your hosts for support and advice.

Suggestions regarding directory restrictions noted.
 
I'm not criticizing, just making an observation. It's something the XF framework should address, with a file API that has both a native and an ftp adapter, like the J! framework does. So then it's up to the site admin which method they use on a global basis. But it seems we're still kinda stuck in the vB world of "make sure the following folders are set to 777" days.

I would just suggest that people approach this permissions issue with caution. If you have sufficient access to your server, it's easy enough to add the necessary 'group' or 'other' write permissions to the whole of the XF web root while you use the installer, then remove them when you are done. I've been administering systems for a long time, and this may seem like a pain to do, but I can promise it will greatly decrease your chances of being hacked.

Don't get me wrong, I love this addon. I used it's predecessor on vB since day one. And I've always taken the same precautions. It just goes against the grain when I see people being advised to open up write access on web content for the web server itself.

-- hugh
 
Top Bottom