oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: svn commit: r962827 - /incubator/amber/trunk/spec-api/src/main/java/org/apache/amber/OAuthRequest.java
Date Sun, 11 Jul 2010 12:12:40 GMT
I'd suggest to let provider adopt his own policy, BTW someone else
feedback would more than welcome. Come on guys, don't be shy! :)

PS Pid, why don't you start committing your concrete stuff under the
client module? It would be easy see the progresses.

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, Jul 11, 2010 at 2:06 PM, Pid <pid@pidster.com> wrote:
> On 11/07/2010 13:01, Simone Tripodi wrote:
>> OK, so going to replace URL using URI, sounds a good compromise.
>>
>> I wouldn't force clients to the automatic correction. Users have to
>> know the risks using PLAINTEXT without SSL, as explained in the spec
>> notes...
>
> So throw an exception then, or let the server reject it?
>
>> Does someone else have other ideas?
>
> Yes.  Anyone?
>
>
> p
>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, Jul 11, 2010 at 1:44 PM, Pid <pid@pidster.com> wrote:
>>> On 11/07/2010 12:26, Simone Tripodi wrote:
>>>> I understand well your point of view. So, a good compromise can be
>>>> reached using the URI class; users can use that[1] method to create
>>>> urls in a "safety" way.
>>>> In the signature part, we need to acces to various URL part (protocol,
>>>> host, port) and I wouldn't rewrite a parse at all.
>>>
>>> Crap, yes, you're right of course.  URI is a good solution.
>>>
>>> WDYT about automatically correcting a plaintext+http request to https?
>>>
>>>
>>> p
>>>
>>>> WDYT?
>>>> Simo
>>>>
>>>> [1] http://java.sun.com/javase/6/docs/api/java/net/URI.html#create(java.lang.String)
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Sun, Jul 11, 2010 at 11:53 AM, Pid <pid@pidster.com> wrote:
>>>>> On 11/07/2010 10:41, Simone Tripodi wrote:
>>>>>>>
>>>>>>> I think maybe the requestURL should be a String too - I'm trying
to
>>>>>>> handle all of the IOExceptions in the HttpConnector.
>>>>>>>
>>>>>>
>>>>>> discouraged. making the requestURL as a proper URL saves to check
the
>>>>>> string is a proper URL and we shouldn't reinvent the wheel.
>>>>>
>>>>> The requestURL is only passed to the HttpConnector, nowhere else.
>>>>>
>>>>> It will start as a String somewhere in the system, so we have to catch
>>>>> an IOException to create the URL object.
>>>>>
>>>>> This isn't a case of reinventing the wheel at all, it's a case of
>>>>> putting all of the IO operations/checks associated with making the
>>>>> request in one place.
>>>>>
>>>>> I don't see any advantage in doing that try+catch at anywhere before
the
>>>>> IO processing begins.
>>>>>
>>>>>
>>>>> The related issue is whether to validate the request before making it
-
>>>>> which will probably be necessary in the case of checking the plaintext
>>>>> method is an HTTPS one.
>>>>>
>>>>> Leading on from that, if we automatically* upgraded the plaintext
>>>>> connection to HTTPS, it would mean recreating the URL object, complete
>>>>> with try+catch etc, rather than a simple String regex.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> * Checked via a system property, defaults to 'on'
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>

Mime
View raw message