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

@ Symbol for $pass #8

Closed
kwaimind opened this issue May 2, 2014 · 7 comments
Closed

@ Symbol for $pass #8

kwaimind opened this issue May 2, 2014 · 7 comments
Assignees

Comments

@kwaimind
Copy link

kwaimind commented May 2, 2014

Hey

I was testing the $pass option using passwords beginning with @ and noticed that a pass starting with the @ symbol cause a bad authentication. When trying to run via a the command line, it reports back with Login Failed!.

Hope you can look into this.

Dan

@eyecatchup
Copy link
Owner

@kwaimind You may have noticed that the script sends login data in a cURL POST request. Depending on the PHP version the data is being send as either an array or as a URL-encoded string.

So, just a blind guess.. But may it be related to this? Or does it happen only when the @ symbol is the first character of $pass?

@eyecatchup eyecatchup self-assigned this May 7, 2014
@kwaimind
Copy link
Author

kwaimind commented May 7, 2014

Hey @eyecatchup , thanks for the update. Yes that is exactly when it happens. If I change the first symbol to a normal text character there is no issue. I hope that helps!

@eyecatchup
Copy link
Owner

Okay, I think I know what happens.

When feeding CURLOPT_POSTFIELDS with an array, internally curl's field option -F is used. The regular field switch (-F), however, interprets a leading @ symbol for the value as an instruction to not POST the field/value data, but instead to send the file name that immediately succeeds the symbol (as part of the POST).

The curl command line, fortunately, offers another option '--form-string', which behaves the same way as '-F', except that the 'form-string' option is not parsed.

As an example, if you want to use curl to POST field1 with value "@value" and file1 with the file "testfile.txt" you can do so as follows:
curl "http://www.url.com" --form-string "field1=@value" -F "file1=@testfile.txt"

Even though there's no direct syntax of this in using PHP's cURL, you can still work around the issue, by the use of http_build_query() on your data-array first before passing it to curl_setopt(). That will lead to it sending the form as application/x-www-form-encoded instead of multipart/form-data and thus the @ symbol is not interpreted.

I'm gonna commit a patch for it now, which should fix this issue. Would be nice if you could verify that it works now, @kwaimind.

@eyecatchup
Copy link
Owner

Fix is live

@eyecatchup eyecatchup added bug and removed enhancement labels May 8, 2014
eyecatchup added a commit to eyecatchup/GWT_IndexStatus-php that referenced this issue May 8, 2014
Curl's default -F switch interprets a leading @ symbol for the value as an instruction to not POST the field/value data, but instead to send the file name that immediately succeeds the symbol (as part of the POST). In order to be able to use passwords starting with an @ symbol, POST data is now being send as application/x-www-form-encoded instead of multipart/form-data whenever a password value starts with an @ symbol. (See eyecatchup/GWT_CrawlErrors-php#8 for further reference.)
eyecatchup added a commit to eyecatchup/GWT_IndexStatus-php that referenced this issue May 8, 2014
Curl's default -F switch interprets a leading @ symbol for the value as an instruction to not POST the field/value data, but instead to send the file name that immediately succeeds the symbol (as part of the POST). In order to be able to use passwords starting with an @ symbol, POST data is now being send as application/x-www-form-encoded instead of multipart/form-data whenever a password value starts with an @ symbol. (See eyecatchup/GWT_CrawlErrors-php#8 for further reference.)
eyecatchup added a commit to eyecatchup/php-webmaster-tools-downloads that referenced this issue May 8, 2014
Curl's default -F switch interprets a leading @ symbol for the value as an instruction to not POST the field/value data, but instead to send the file name that immediately succeeds the symbol (as part of the POST). In order to be able to use passwords starting with an @ symbol, POST data is now being send as application/x-www-form-encoded instead of multipart/form-data whenever a password value starts with an @ symbol. (See eyecatchup/GWT_CrawlErrors-php#8 for further reference.)
eyecatchup added a commit to eyecatchup/php-gwt-sitemapuploader that referenced this issue May 8, 2014
Curl's default -F switch interprets a leading @ symbol for the value as an instruction to not POST the field/value data, but instead to send the file name that immediately succeeds the symbol (as part of the POST). In order to be able to use passwords starting with an @ symbol, POST data is now being send as application/x-www-form-encoded instead of multipart/form-data whenever a password value starts with an @ symbol. (See eyecatchup/GWT_CrawlErrors-php#8 for further reference.)
@kwaimind
Copy link
Author

kwaimind commented May 9, 2014

Yep @eyecatchup, that looks like its fixed now. Thanks so much!

@eyecatchup
Copy link
Owner

👍

@eyecatchup
Copy link
Owner

@eteled START

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

No branches or pull requests

2 participants