Welcome! I’m not sure I fully understand your question, apologies if my answer is to a question of my own imagining and not yours.
I’m not sure if your API calls are javascript/jquery or PHP, or something else, the answer changes by language. Javascript/jquery is sent out to the client so no sensitive information should be handled this way. So I’m assuming you’re referring to PHP.
While it’s not a problem storing code in the DB, I don’t see the point. Code contained in a .php file should never be visible to users if the server is properly configured. Still, error messages, even without displaying code, is a security risk. The display is typically managed in wp-config.php with the WP_DEBUG constant. Defining it as false should hide all messages from users, provided once again if the server is properly configured.
If the configuration is not right, there is usually some recourse. The details are discussed here: https://codex.ww.wp.xz.cn/Editing_wp-config.php#Configure_Error_Logging
Thanks for the response, bcworkz!
Just to clarify, the API call is in PHP, and when I was referring to the DB, I was referring to storing the API key itself (not the code that calls it).
As for controlling the error output via wp-config.php (WP_DEBUG), this would only be feasible if I was the only one using the plugin. If that were the case, I would simply change my own settings. However, I do plan on pushing this out to the community in the future, so modifying wp-config.php for other WP users is not feasible.
The problem I’ve seen is that for certain PHP Warnings, it’ll output my API call to the browser, which contains the API key. I need to prevent this from displaying.
I don’t know much about try/catch for exception handling, but how could this be applied to warnings, notices, errors, etc.?
I hope that makes sense.
Thanks!
OK, much clearer now, thank you! I don’t have a real answer for you, but some random thoughts.
I’m mystified how the API key is displayed in normal PHP error messages. Typically only the function name is displayed. In any case it is happening and must stop. Perhaps it is from the API output and not PHP? If so, the API is quite poorly written IMO.
Not an excuse, but the API key shown would not be yours, but that of the installation site. (Please say it is so!) It must be hidden from the public, but not the site admin.
Typically, production servers would have WP_DEBUG as false and output any errors to a non-public error file. Alas, this is beyond your control, but to do otherwise is really the site admins fault for not protecting their own API key. If the key exposure is from the API, this aspect is moot anyway.
Ideally, your code should be completely compliant such that even minor notices are not output. I realize compliant now may not be compliant tomorrow. Do your best.
Exception handling is a must have for anticipated operational errors like missing files. Unanticipated errors are impractical to handle this way, but perhaps an API error could be handled this way. It would depend on the specifics of the API call.
Hey bcworkz –
Thanks for your response. I really appreciate you taking the time to explain!
Correct, the API shown would be that of the publisher in charge of the installation site. I understand WP_DEBUG, but can’t assume everybody will set this to false 🙂
Personally, I have a security plugin named Bullet Proof Security that handles this. There’s an option to “display errors” (including warnings, notices, etc.). Their recommendation is to set it to OFF, which I did. I’m pretty sure they somehow handled this via .htaccess, but don’t know for sure.
As for the API call itself, all I’m doing is calling a URL that contains the API key within it. This is where I think the hiccup *could* occur. I then store the XML string into an XML object using simplexml_load_string(), but I think that at this point I’m safe if the URL containing the API key was well-formed.
Thanks
I’ve solved my problem and decided to post here in case anybody needs it. I used:
set_error_hander()
prior to the warning I wanted to capture, and then used
restore_error_handler()
afterwards.
