Front end>admin edit--Possibly IP address spoofing concern, but man I like this...

So assuming this isn't overwhelming shot down as bad coding

1.5.5e

includes/templates/your_template/templates/tpl_product_info_display.php

...down around the details/info...

$allowedips = array('**.***.***.**', '**.***.***.**', etc.);
if(in_array($_SERVER['REMOTE_ADDR'],($allowedips))){
?>
<li><a href="https://www.your_website.com/YOUR_ADMIN/product.php?cPath=<?= $_GET['cPath']; ?>&product_type=1&pID=<?= $_GET['products_id']; ?>&action=new_product&search=<?= $_GET['products_id']; ?>" target="_top" accesskey="w">Edit Product##########____(Alt+w)</a></li>
<?php
}

I have a bunch of other work arounds including a take in/out of stock which works w/ ajax as a button.

anyone see any reasons why I shouldn't try to make my first add-on w/ some of this logic?

I was also hoping to maybe put the ip addresses in the configuration table but couldn't figure out writing the sql logic that typically comes w/ installers, and then this is also it's potentially a bad idea in that it's risky I'm guessing.

There are a number of complex PCI compliance hoops to go through when enabling front-end admin-live-editing like that, which is why such a feature isn't in the core code.

To answer your question about IPs, often the EXCLUDE_ADMIN_IP_FOR_MAINTENANCE constant is used to do IP-specific access control, since it's already easily configurable in the Admin.

Additionally, as for a few improvements to the above: there are a number of things that are locked in: the product type being product on the parameter list, the file to perform the editing being the main product type. Use of short type php tags is generally discouraged because they are not always supported under all php configurations (ie. Instead of using '<?=', use the expanded '<?php echo' format.

As for the functions to lookup the product type and other factors, these can be found generally in the includes/functions folder in files such as functions_lookup.php and functions_general.php. Others may have as well and can be used without specific reference to those files.

So I'm finally realizing the folly of this approach, and I was wondering if anyone had a suggestion of a more secure approach. Using port #'s doesn't seem to work (private ip addresses not seemingly available, only public). I'm thinking of trying to do a browser cookie based approach but know very little about them.

Any suggestions?

so I had a few locations giving special functionality in code using:

if(($_SESSION['customer_id'] == 123) || (strstr(EXCLUDE_ADMIN_IP_FOR_MAINTENANCE, $_SERVER['REMOTE_ADDR']))){
//CONVENIENT ADMIN LINKS
}

Would there be a way to detect the admin's log-in session in php from the catalog side? and if statement around that?

wolfderby:

Would there be a way to detect the admin's log-in session in php from the catalog side? and if statement around that?
That's not a built-in feature, no. I mentioned some reasons in my posts above.

So I've taken to wrapping this logic from a while ago from within a browser cookie that can only be set by logging into the admin to set it. I have some fun hacks to the front end now that add admin functionality but they generally would rely on this sort of "inserting-admin-stuff-into-catalog-side-stuff" being PCI compliant. I was wondering if it'd be possible to do so as an add-on, which I could then make a dependency of other add-ons. Any thoughts on this?

so... something like...

 if(isset($_COOKIE['specialAdminKeyCookieName'])){
//then do cool stuff like show jQuery stock status toggle button, 

//or 

//show checkbox for showing out-of-stock status stuff in search results

//or

//give button to jump directly to editing this product in admin

}

I also have hacks that allow you to live edit the price of products in the shopping cart, and allow you to post date the order, and change the mail-to email address of an old order to only email your company/in-house email (so they don't get spooked)