I created a ckeditor 4.62 - update - plugin under Xampp 7.0  which i copied with sftp  to debian 7 php5.6 under addons/ckup462  and the installation was successful.

Then i pblished the plugin in the repository and installed it from the management - console on another system with apache 2.4/php7.1 solaris , but the unzip of the contained  ckeditor64.zip failes there. Only a folder ckeditor64 is created parallel to ckeditor_34. The  plugin appears not under addons, but it is  in the list of the installed plugins. I cant find it anywhere.

If i go with the mouse over the heading i see  http://www.site.info/sub/Admin/Addons/Y2t1cDQ2Mg . But Y2t1cDQ2Mg is not under addons...

I install the plugin with a special admin-link,   and this leads to :  http://www.site.info/sub/Admin_Update_to_462  and is executed, but the unzip fales here.

[Admin_Link:Update_to_462]
label = 'Update_to_462'
script = 'copyfold.php'
class = ' '

Can i make a simple entry  that the plugin is installed under addons and my copyfold.php is automatic executed when the plugin is installed ?

The addon.ini has its traps.  Who has experiences ?

 

 

apache 2.4/php7.1 solaris

Is it really a (Oracle) Solaris webhost? Quite uncommon.

 

The  plugin appears not under addons, but it is  in the list of the installed plugins. I cant find it anywhere.

Remote installed addons will be in /data/_addoncode/[7-random-characters]

but the unzip fales here.

Have you set

define('gpdebug',true);

in /gpconfig.php ?

Or do you have access to apache's error.log?

 

class = ' '

AFAIK you don't need this line.

 

It is Solaris 5 with apache2.4 and php7.1 -- But i think the unzip fails, because the path of the Zipfile in the php  is relative to the root  /addons/--ckup46 ( i dont know a variable with   \data\_addoncode\xxxx) . 

But i have remote installed plugins in  addons/--AntiSpamMath and in addons/--Easy_Comments and more.

The exploitchecker installed in  \data\_addoncode\q0wk1qz

Is there no parameter which causes the installation like the two above (it should be added to the master if not)

i dont know a variable with \data\_addoncode\xxxx

It's $addonPathCode for the file system path (full path from root) and $addonRelativeCode for the relative path from the server's document root.
You need to make them global to access them in your functions/methods.

global $addonPathCode;

AntiSpamMath and Easy_Comments are included in the master ZIP from Github (but not in regular releases), therefore they can be installed via Plugins -> Manage -> Available.
e.g. Exploitchecker and all plugins you install inline via Plugins -> Download are extracted to the /data/_addoncode/[random characters] directories.

 

 

I had already looked at something like

[Gadget:Child_Thumbnails]
script                = 'Child_Thumbnails.php'

and  $dir = dirname(__FILE__);

OK : If there is no way around then i will rewrite the code - it  delays me only a further day...

But i propse a method which allows to choose the installation directory under /addons !

But i propse a method which allows to choose the installation directory under /addons !

Plugin installations in /addons and /data/_addoncode are two different things.

The former, AKA 'Developer Installation', requires manual download and file extraction to the /addons directory.
Then the addon is 'available' via Plugins -> Manage -> Available. Its files will not be deleted when it is uninstalled, therefore it can safely be edited, uninstalled, reinstalled and 'upgraded'.
It's mainly for developers and it requires file system access.

Remote/inline intallations via Plugins -> Download will be extracted to /data/_addoncode/1x2y3z4. All files will be removed completely when the addon is uninstalled.
This method doesn't require file system access. Similar applies to themes (/themes vs. /data/_themes)

During normal operation, Typesetter will only write to the /data directory.
All settings, content, uploaded files, downloaded plugins and theme/layouts and their derivates will be stored in subdirectories of /data.
(Exception: Typesetter will try to write outside of the /data direcory when 1) the CMS itself is updated or 2) when permalink settings are changed - then Typesetter will try to rewrite /.htaccess - or show further instructions if it fails).

So, normal Typesetter installations will only require write permissions for the /data directory (and it's subdirs). The CMS will not create any (directly executable) script entry points here and admins won't be able to do so via the CMS user interface. This makes Typesetter pretty secure.

But, again, there is an exception: Remote installed plugins and themes.
Although they shouldn't, both plugins and themes may contain insecure entry points. They tend to do so, it's a well proven fact with every CMS, not only Typesetter.
Therefore, putting remote plugin and theme code into randomly named folders is at least a good measure to secure the site against scripted attacks targeting weak/insecure addons.

Of course, anyone with file system access can do all sorts of evil or stupid stuff. Typesetter admin accounts cannot (at least, I haven't yet found a way).
That's what the different installtion types are mostly about. It's a good security measure and we should keep it and not mix them up.

Thanks for Your long answer.  The plugin is online - the only problems i can find at solaris 5 is with the deletion of the backup directory, but it has often problems that a directory is unaccessible after deletion of its contents. If codeproblems are removed and wanted i can make further plugins with higher ckeditor versions.

Out of curiousity: Can't find no traces of Solaris version 5. There was ver. 2.6 in 1997, then ver. 7 in 1998. Current ver. is 11.3 (2015).

For  a short time a solaris(sunOS) 5 - link for demonstration. No virtual directories !

All their shared hosting is built with this.

If the system deletes a directory, and it is empty but still there, then it is only deletable with ssh .

I had that  several times. After days the directory was accessible again and empty but not deletable.

After creating an empty file with filezilla in that directory a part of the deleted files reappeared.

You should add

defined('is_running') or die('Not an entry point...');

at the top of the php scripts.
Currently the scripts can be called directly and might cause unwanted results because of then empty variable values (such as $addonPathCode).

Yes thanks,  i did that.

I also found that several ckeditor-plugins  have a limited functionality (my font-plugins and also Roboto) if a Javascript-Blocker like Noscript is active.

In the case of this Firefox-plugin it is possible to deactivate it or to put 'localhost' and the specific website into the list of positives.

The better solution would be to let ckeditor run in a kind of sandbox(like Adobe), which a scriptblocker cannot reach.

There is a limited example for ckeditor on github, but who can program that...

I also found that several ckeditor-plugins  have a limited functionality (my font-plugins and also Roboto) if a Javascript-Blocker like Noscript is active.

What else would you expect from a JavaScript blocker? CKEditor is a pure JS application.
The whole concept of Noscript, uMatrix, uBlock Origin, you name it, is about manual whitelisting.
They put you, the user, in charge to decide which content you trust and allow to load.
That of course comes with a price tag.

The better solution would be to let ckeditor run in a kind of sandbox(like Adobe), which a scriptblocker cannot reach.

If it was possible, any script would use such 'bypass script blocker' techniques, even the nasty ones.
Flash (and other browser plugins) are a different story. They are locally installed software.

A final question :  Looking at my ckeditor repository i see

Minimum Typesetter Version   (empty)  

Used Most with Typesetter Versions 2.0.0   5.1.0

But my addin.ini is not unusual.

What does the addon -  parameter  namespace = example  mean

 

Minimum Typesetter Version   (empty)  

Unfortunately it's not shown anymore (probably broken). But you can add it to your plugin description.

Used Most with Typesetter Versions 2.0.0   5.1.0

Oops, I believe version 2.0.0 was in 2010. Must also be a bug. I'd simply ignore it.

But my addin.ini is not unusual.

It's fine.

What does the addon -  parameter  namespace = example  mean

See PHP namespaces.
If defined, Typesetter will encapsulate addon PHP classes in the given namespace.

Since your plugin doesn't use any classes, it won't apply.

 

A short notice to Javascript : The ckeditor functions inspite of the blocker .

If it would be possible to append the additional javascripts to the ckeditor.js ( or to put  them  together  or only to compress and obfuscate them single ). The blocker might not see them then. The blocker seems to look for special js like window.open. 

Fonts which are already in the ckeditor function inspite of a JS-blocker. Maybe something can be improved regarding their implementation via hooks

I also see minify.js in the cms. On github is https://github.com/yui/yuicompressor which does all of it (css, js : compress , obfuscate) - BSD License - it just has the disadvantage that it is a .jar

The blocker might not see them then.

I cannot reproduce any of the issues here.
So that's my conclusive statement on that matter:

Whatever software is causing the problems on your local system, if it blocks content despite explicit whitelisting but on the other hand can be tricked by obfuscation techniques (which bad guys know way better than you and me), it simply is of no value.
Don't fight symptoms but cure the underlying cause. Just get rid of it.

All this doesn't seem to be Typesetter or CKEditor related at all.

You are principally right , but cksource said to this problem long ago that they are responsible for the professional side and not for userplugins.

The next step would be to integrate Ckeditor 5 into Typesetter.

There is an interesting article

https://stackoverflow.com/questions/195149/is-it-possible-to-sandbox-javascript-running-in-the-browser

with links to github-projects. It is possible to let a .js run in a sandbox, but i will have to fiddle out it myself and come back after i have developed a safe method for ckeditor.

 

Any real working JS sandbox will prevent accessing the global scope, where e.g. the CKEDITOR object lives in.

Every CKE plugin I know writes to this object. So, good luck.