[TIMOB-2149] Android, parse problem with URLs that contain @ in username

Note the title should say iPhone not Android

Fixed title to reflect iPhone, not Android.

to scrub

http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt

The authority (Username and host info) is defined as [ userinfo "@" ] host [ ":" port ]

userinfo is defined as *( unreserved / pct-encoded / sub-delims / ":" )

unreserved is defined as ALPHA / DIGIT / "-" / "." / "_" / "~"

pct-encoded is defined as "%" HEXDIG HEXDIG

sub-delims is defined as "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

In none of userinfo is "@" allowed as a valid character.

Per rfc 3986, the URI is requesting host of demandocat.com, port 'testing', which is an invalid number. Thus, this URI is invalid.

To specify a userinfo that would contain the "@" character, it MUST be pct-encoded as "%40"

Invalidated without any evaluation to ensure authentication is possible using this means or test case for basic auth? The ability for a client to pass credentials by this means is very basic functionality. It does not work with this client with iOS.

Before closing or invalidating the ticket, it would be preferable to demonstrate that the functionality performs as expected or repair/assign if it does not. This issue has been satisfactorily repaired for Android with a test confirmation one can now properly authenticate. I feel this has been evaded. This is necessary functionality for web services work and we have a crippled client if it cannot perform basic authentication using this method.

Blain. I can put together something that demonstrates the inability to authenticate by passing credentials in url where doing same in curl succeeds. Passing credentials in this way is a common thing to want to do and this requires a fix.

Hello fairwinds,

Our current situation:

With URLs, we have already gone down the slippery slope in Titanium. I would have preferred that we were strict in the main API, and yet also provide helper functions to encode/decode, escape, where the algorithms are well-documented and understood.

In the coming months we will systematically scrub our API and seek to achieve a good balance between achieving better standards compliance as well providing functionality for ease of use by the end developer.

On this specific issue:

Blain's comment is accurate, that "@" is not allowed in the userinfo, and that if non-allowed characters exist, they should be escaped. In this case if "@" is the userinfo should be "%40".

What we will do:

We'll take the action to discuss this issue internally, as Android and iOS differ in their approach right now.

Thanks for your input, and expect an update on this within a week.

Sincerely,
~Ralf Dir of Platform Engineering

Hi Ralph. Not sure the issue for me was properly characterized by the ticket. The core issue for me is not simply the @ in the name but authenticating via:

http://user:pw@example.com">http://user:pw@example.com or
http://user:pw@example.com">http://user:pw@example.com

neither of which will authenticate using the client. Am quite happy to encode the user:pw string including any @ character that might exist there.

Ralph. One of those examples should be https above, sorry for typo.