Jump to content

Dynamic calling of ACP images


Wolfie

Recommended Posts

I know this would be a rare circumstance to have happen but might not be a bad idea to include anyway. Basically, there may be instances where an ACP image might be wanted for display on the front end and obviously (for security reasons) you don't want to use the full URL to the actual image as it would reveal the name of the ACP folder. Not really an issue if it's the default name and if the option to disable the ACP links isn't being used. But when it is being used, if someone wants to use an image from the ACP structure, it presents a problem.

So I was thinking, what if there was a URL that could be used where the relative path to the image could be sent and then the image file could be read and sent out without revealing the ACP folder name?

Something like this:

		




Shouldn't be that hard to add and could allow the use of ACP images on the front end without having to make copies of them to the public area. Just thought I'd toss the idea out there.

Link to comment
Share on other sites


I know this would be a rare circumstance to have happen but might not be a bad idea to include anyway. Basically, there may be instances where an ACP image might be wanted for display on the front end and obviously (for security reasons) you don't want to use the full URL to the actual image as it would reveal the name of the ACP folder. Not really an issue if it's the default name and if the option to disable the ACP links isn't being used. But when it is being used, if someone wants to use an image from the ACP structure, it presents a problem.



So I was thinking, what if there was a URL that could be used where the relative path to the image could be sent and then the image file could be read and sent out without revealing the ACP folder name?



Something like this:


		




Shouldn't be that hard to add and could allow the use of ACP images on the front end without having to make copies of them to the public area. Just thought I'd toss the idea out there.


I see no truly valid reason as the public images are supposed to be customizable by skin.
Allowing easy access from the front-end to the ACP directory for images only further encourages this practice of breaking this customization method.
Link to comment
Share on other sites

I see no truly valid reason as the public images are supposed to be customizable by skin.


Allowing easy access from the front-end to the ACP directory for images only further encourages this practice of breaking this customization method.


Not everything being shown is meant to be customizable/changeable per skin set. I'm talking about static images being shown with a dynamic URL when those images are ACP images but wanted or needed to be shown on the front end. Nothing to do with skin customizations.
Link to comment
Share on other sites

Why not go the opposite route and put all images that may need to be accessed this way on the public side, and have the Admin CP access them from there? That way, the images can be grabbed from either side without revealing any sensitive Admin path info on the public side?

Link to comment
Share on other sites


Not everything being shown is meant to be customizable/changeable per skin set. I'm talking about static images being shown with a dynamic URL when those images are ACP images but wanted or needed to be shown on the front end. Nothing to do with skin customizations.



Lets take your example link... aff_tick.png.
Put it on a green skin.
Every single image used in the front-end should be customizable by skin.... you cannot know what color set the skinner will use.
Link to comment
Share on other sites

Why not go the opposite route and put all images that may need to be accessed this way on the public side, and have the Admin CP access them from there? That way, the images can be grabbed from either side without revealing any sensitive Admin path info on the public side?


I love this idea but get the feeling that it wouldn't ever be done. Thus asking for a way to dynamically call on ACP images. Putting them all in the public/ folder would be best though, as it opens up a lot of possibilities.


Lets take your example link... aff_tick.png.


Put it on a green skin.


Every single image used in the front-end should be customizable by skin.... you cannot know what color set the skinner will use.


That would be up to the person designing the need/use of the ACP image to correct or account for. Otherwise to use your argument, the ability to choose colors in posts should be removed because what if someone chooses to use green text and then the site switches to a green based skin? That text would virtually disappear. Let's get it possible first, and then when it's used, if the use of the images generates a problem with appearance, fix it then.
Link to comment
Share on other sites


Why not go the opposite route and put all images that may need to be accessed this way on the public side, and have the Admin CP access them from there? That way, the images can be grabbed from either side without revealing any sensitive Admin path info on the public side?




I love this idea but get the feeling that it wouldn't ever be done. Thus asking for a way to dynamically call on ACP images. Putting them all in the public/ folder would be best though, as it opens up a lot of possibilities.




It is a feature.


$this->settings['img_url'] is valid in the ACP..... so now I'm confused.


What is stopping you from taking the better suggested route?




That's for public images, not ACP images.



Read please..... I'm quite certain it shall sink in.
Link to comment
Share on other sites

Read please..... I'm quite certain it shall sink in.


1. To do it myself via an install hook won't always work. If an image cannot be copied for whatever reason, then the process fails. This could be due to security preventing the images from being copied.
2. To create the feature myself as a hook would be cumbersome because to install it by itself would be pointless and to make other hooks, etc, use it would require it to be installed and as a result would rely on something that may not be there.

Thus, it being done by default would be best.
Link to comment
Share on other sites


1. To do it myself via an install hook won't always work. If an image cannot be copied for whatever reason, then the process fails. This could be due to security preventing the images from being copied.


2. To create the feature myself as a hook would be cumbersome because to install it by itself would be pointless and to make other hooks, etc, use it would require it to be installed and as a result would rely on something that may not be there.



Thus, it being done by default would be best.



:baby: :no:
Wolfie.... Put them in the /public/style_images/master/ directory to be uploaded.
Use $this->settings['img_url'] in the ACP and be happy!
Link to comment
Share on other sites


You obviously missed my point.



No... I did not.
You do not need a mod to do what you seek.
You simply need to think around your supposed need to access ACP Images from the public side, and access the public images from the ACP.
The excuse that someone might not upload it to their skin sets is thin these days.... it is in both the documentation and just about every mod installation readme.
I would be highly open to a better method of handling that, as a note.
Link to comment
Share on other sites


No... I did not.


You do not need a mod to do what you seek.


You simply need to think around your supposed need to access ACP Images from the public side, and access the public images from the ACP.


The excuse that someone might not upload it to their skin sets is thin these days.... it is in both the documentation and just about every mod installation readme.


I would be highly open to a better method of handling that, as a note.



Oh... and for that matter... you want static?


$myacpimgurl = str_replace($this->registry->output->skin['set_image_dir'], 'master', $this->settings['img_url']);


There... using that in the acp you will always have the master img url.
Strictly speaking... there are more reasons not to call upon the ACP directory from the front-end than there will ever be to not call upon the front-end from the back.

Link to comment
Share on other sites

No... I did not.


Yeah you did.

You're thinking of grabbing public images from the ACP, which isn't what I want to do.

You're thinking that I'm trying to make use of images that are included with skinsets, which there are many images that are used in the ACP that aren't available on the public side.

I made a feature request which I believe would have benefits. I understand your concern about incompatibility with skins, but there are many things that could create such an issue.
Link to comment
Share on other sites


Yeah you did.



You're thinking of grabbing public images from the ACP, which isn't what I want to do.



You're thinking that I'm trying to make use of images that are included with skinsets, which there are many images that are used in the ACP that aren't available on the public side.



I made a feature request which I believe would have benefits. I understand your concern about incompatibility with skins, but there are many things that could create such an issue.



The concern goes far beyond skin sets Wolfie.


It would have to reveal way too much of the ACP application file structure to be fully utilized.

Link to comment
Share on other sites

It would have to reveal FAR too much of the ACP application file structure to be fully utilized.


The structure inside the ACP folder remains the same. The ACP folder name itself is what needs to be kept private for security purposes. Of course, the example I gave was to show what exactly I was referring to. It could be something simple like '?act=acpimage&app=ccs&image=images/differences.png' which would reveal very little. The overall concept remains the same.
Link to comment
Share on other sites

And CDN?


CDN.. Can Do Nothing. :P


:tongue: this simply cannot work well for all involved is my only real point.... I have no use for it, but I'm sane(?) and simply copy the image over if its that ungodly important for something in the front-end.


Benefit would be to avoid having to do that if the image already exists instead of duplicating it.
Link to comment
Share on other sites


CDN.. Can Do Nothing. :tongue:





Benefit would be to avoid having to do that if the image already exists instead of duplicating it.



You just named the drawback.... IPB Owners could no longer reliably depend on being able to push static images for front-end use through any CDN....
Considering a CDN is in use here.... need I really say more?
Link to comment
Share on other sites

You just named the drawback.... IPB Owners could no longer reliably depend on being able to push static images for front-end use through any CDN.


I was toying with what CDN stands for. Not only that but I was saying that CDN can do nothing.

Why are you so determined to derail this suggestion anyway?
Link to comment
Share on other sites


I was toying with what CDN stands for. Not only that but I was saying that CDN can do nothing.



Why are you so determined to derail this suggestion anyway?



Because it stands as a cry against the entire MVC concept.... and developing on IPB.... it is directly against the entire principle of the ACP being separated from the front-end.... and the skin system.
Not gonna Lie or mince words, take it or leave it.... I'll leave your topic alone then.
Link to comment
Share on other sites

What's the ultimate goal here, Wolfie? I was under the assumption this would be for something you'd be creating as an addon. There shouldn't be any need for the core product to be able to do this: the public side only needs to refer to public images, and the admin side has its own images and public-side images it can access safely.

Is it just that there are images that are currently in the admin folders that you'd like to use somehow on the public side? If you can explain what the need is, it would help with coming up with solutions.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...