Upload class allows for files that will not be saved to the file system #468

wants to merge 2 commits into


None yet
5 participants

This modification to the file uploading class allows for files to be dealt with instead of moving/copying them to the file system. This is really handy if you intend to store the file in a database or send it to another server via FTP.

skunkbad commented Oct 1, 2011

Any comments would be appreciated...

@@ -107,6 +108,7 @@ public function initialize($config = array())
'xss_clean' => FALSE,
'temp_prefix' => "temp_file_",
'client_name' => ''

dbowling Mar 27, 2012

This is missing a comma.

Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting ')' in D:\www-life\apps\dev\dan\uds-cbord-to-excel-stable\application\libraries\MY_Upload.php on line 111


skunkbad Mar 27, 2012

Yeah. Thanks. I just deleted the repo. I'm not interested in maintaining it.


cryode commented Oct 13, 2012

So @skunkbad do you want this to be taken into consideration anymore, or should it be closed for the time being?

It's been a long time since I submitted it, but still feel it's a necessary feature.


cryode commented Oct 15, 2012

You should make sure it is up-to-date (won't cause merge conflicts), and add relevant user guide and change log info.

Looking back, it looks like I deleted the repo about 7 months ago. At the time I figured that whoever was responsible had enough time to look at it, and that it was just clutter on my dashboard. Although I think it's a necessary feature, because I use it every day, I don't know that I can make this pull request work because of the deleted repo. I'll just close this pull request, and when I get time I'll reopen it with a new repo. It's doubtful anyone was really interested in it anyways, because it's been "about a year" since I created the pull request.

Another thing would be that due to my understanding of the CI 3.X license change, I'm not even sure I'll be able to use CI 3.X, so why bother? The type of client that I want is not the type that would want to comply with the license terms as I understand them. See http://codeigniter.com/forums/viewthread/202562/ . I'd be all in with guns blazing if it weren't for the license, but instead I'm with what I believe is the majority, and considering other frameworks.

@skunkbad skunkbad closed this Oct 15, 2012


narfbg commented Oct 17, 2012

I don't want to start another long discussion on the license change, but after reading through that forum thread I came to the same conclusion that I already knew before that - you're not obliged to do anything unless you hack the files under the system/ dir. So what's the problem with that?

Read EllisLabs Compliance Examples: http://ellislab.com/blog/comments/codeigniter_osl_3.0_compliance_examples . You'll find that compliance means revealing the source, even if you're a "tinkerer".


dchill42 commented Oct 17, 2012

I didn't get that at all. My read on the new license and examples was that anything you didn't download from CI and directly change is yours and can be hidden. They seemed to express that they'd like people to say they're running CI (for obvious reasons), but not that it's required in any way. I even got the impression that if you wrote code changing CI itself, how you make that code available is entirely flexible (e.g. - mailing copies on demand).

The biggest issue I came across was that GPL'd code used in conjunction with CI may raise issues due to the GPL constraints (not the OSL ones).

A quote from the compliance examples page:

How did I decide to reasonably make the source code of the OSL 3.0 licensed CodeIgniter files on my site available for those who want it? I have a Powered by CodeIgniter link in my footer that points to the official GitHub repo. CodeIgniter rocks!

It's not optional if you want to be in compliance, hence the language "reasonably make the source code of the OSL 3.0 licensed files on my site available". Remember, this is from the "tinkerers" section, which means it applies to everyone. You'll have to be the judge regarding what reasonably making the source code available means, but what it means for me is that my client cannot use v3.X without revealing the source code (not the application directory). That means revealing the technology that your site is built with.

I understand that the application files are not part of what needs to be made available, but it's the system files that give away what your vulnerabilities might be. Further, PCI compliance has always made it clear that revealing server technology is bad, so how can this be good? Knowing that a site is made with CI 3.X means that a potential attacker knows you're running on PHP, and they have the entire system files to look through to see if they can find a security vulnerability. Even with as mature as CI is, let's not fool ourselves about the potential bugs and security issues. The license just doesn't fit with the type of customer that I want to work with, and it's my opinion that it's not smart for anyone except EllisLab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment