Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POST <html> from php curl comes escaped - deal with it receiver-side? #39

Open
labor4 opened this issue Sep 28, 2016 · 6 comments
Open

Comments

@labor4
Copy link

labor4 commented Sep 28, 2016

Hi
I'm using the API to build a submit connector for inserting whole <html> content with campaignAdd() to phplist.
It seems to me that the sender's php curl must escape all quotes. So receiver-side the code is not valid as-is.
In the API (include/campaigns.php) i need to do:
stripslashes($_REQUEST['message'])

Is this something to consider for you DEVs, or am I only doing a bad approach?

Thanks
Best
Manu

@michield
Copy link
Member

Yes, there's an annoying discrepancy that needs a fix, which is quite tricky

phpList handles the content by duplicating the escaping somewhere. I haven't found it yet. The complication will be to make sure that a campaign added by phpList UI and phpList API are entered the same way. This is currently not the case, IIRC.

@labor4
Copy link
Author

labor4 commented Oct 21, 2016

(I dont know if the Email reply worked correctly, so this could become duplicated)

Hi Michiel
Are you sure the core functionality is the issue?

Is is not that the API provides the case that finished Code is inserted (which is usually not the case with the GUI),
and this is a very special case where an outside factor delivers a very special flavour of "material" (php curl)?

So I suggest it's more about handling the "special case", for example by giving a switch in the REST to tell the API to clean up?

Best
M

@labor4
Copy link
Author

labor4 commented Oct 25, 2016

Hi Michiel

Are you sure the core functionality is the issue?

Is is not that the API provides the case that finished Code is inserted (which is usually not the case with the GUI),
and this is a very special case where an outside factor delivers a very special flavour of "material" (php curl)?

So I suggest it's more about handling the "special case", for example by giving a switch in the REST to tell the API to clean up?

Best
M

Am 20.10.2016 um 23:10 schrieb Michiel notifications@github.com:

Yes, there's an annoying discrepancy that needs a fix, which is quite tricky

phpList handles the content by duplicating the escaping somewhere. I haven't found it yet. The complication will be to make sure that a campaign added by phpList UI and phpList API are entered the same way. This is currently not the case, IIRC.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #39 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ARnpb56Y-bOzw1UXgbkbeVhCq6vxP7OQks5q19izgaJpZM4KJBeF.

@michield
Copy link
Member

No, I'm not sure. It would need digging deeper to find out. Unfortunately I don't currently have the time for that.

@kofein
Copy link

kofein commented Apr 5, 2017

admin/inc/magic_quotes.php - looks like this "experiment" is bad

@kofein
Copy link

kofein commented Apr 5, 2017

as temporary solution remove slashes in admin/plugins/restapi/includes/campaigns.php:102 $stmt->bindParam('message', stripslashes($_REQUEST['message']), PDO::PARAM_STR);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants