See
<https://ci-builds.apache.org/job/Tomee/job/Pull%20Requests/org.apache.tomee$openejb-ejbd/7/display/redirect>
See
<https://ci-builds.apache.org/job/Tomee/job/Pull%20Requests/org.apache.tomee$openejb-ejbd/6/display/redirect>
See
<https://ci-builds.apache.org/job/Tomee/job/Pull%20Requests/org.apache.tomee$openejb-ejbd/5/display/redirect>
See
<https://ci-builds.apache.org/job/Tomee/job/Pull%20Requests/org.apache.tomee$openejb-ejbd/1/display/redirect>
See
<https://ci-builds.apache.org/job/Tomee/job/Pull%20Requests/org.apache.tomee$openejb-ejbd/50/display/redirect>
See
<https://ci-builds.apache.org/job/Tomee/job/Pull%20Requests/org.apache.tomee$openejb-ejbd/49/display/redirect>
ogin via the RemoteInitialContext parameters and have their
>>> identity propagate with their remote calls.
>>>
>>> The only change is that the user/pass could get applied at the http layer
>>> as well.
>>>
>>>
>>> This is unrelated to my comment. Point was we can use it with multicast -
>>> which is the only issue - cause outside of the multicasted info - the
>> url.
>>>
>>>
>>> Nothing we couldnt enhance but as explained this is also not needed and
>>> your example doesnt show this is wrong.
>>
>> I’m quite lost. Can you post a code snippet on how someone uses basic
>> auth from the client side with httpd+ejbd?
>>
>> -David
>>
>>
use it with multicast -
> > which is the only issue - cause outside of the multicasted info - the
> url.
> >
> >
> > Nothing we couldnt enhance but as explained this is also not needed and
> > your example doesnt show this is wrong.
>
> I’m quite lost. Can you post a code snippet on how someone uses basic
> auth from the client side with httpd+ejbd?
>
> -David
>
>
t enhance but as explained this is also not needed and
> your example doesnt show this is wrong.
I’m quite lost. Can you post a code snippet on how someone uses basic auth
from the client side with httpd+ejbd?
-David
Le 6 déc. 2016 23:15, "David Blevins" a écrit :
> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau
wrote:
>
>> You may have a desktop app or some other scenario where on your trusted
>> network, users can log in and you don’t want identity statically
configured
>> on the server side.
>>
>>
> This
> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau wrote:
>
>> You may have a desktop app or some other scenario where on your trusted
>> network, users can log in and you don’t want identity statically configured
>> on the server side.
>>
>>
> This is a feature we don't have today at all so qui
gt;> together and broadcasts them to all the clients. Putting the login
> >> credentials in the URL the server broadcasts effectively broadcasts
> client
> >> information to all the clients, which would mean:
> >>
> >> - client identity and credentials woul
On Mon, Dec 5, 2016 at 6:24 PM, David Blevins
wrote:
>
> > On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau
> wrote:
> >
> > Concretely the proposal can be:
> >
> > p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> RemoteInitialContextFactory.
> > class.getName());
> > p.setProperty(Context.PROVIDE
information to all the clients, which would mean:
>>
>> - client identity and credentials would be configured on the server
>> - all clients would share the same identity and credentials
>> - credentials would be freely given to anyone who connects to
>> multicast/multipoin
> multicast/multipoint
>
> The above `authype=basic` compromise does allow the credentials to be part
> of the client configuration, which is great. It allows the same
> credentials the client sends over the ejbd protocol to also be sent over
> the HTTP layer. The client would si
ls to be part of
the client configuration, which is great. It allows the same credentials the
client sends over the ejbd protocol to also be sent over the HTTP layer. The
client would simply be logging in twice, once at the http level and once at the
ejbd level.
-David
2016-12-05 12:56 GMT+01:00 Jonathan Gallimore
:
> On Mon, Dec 5, 2016 at 11:17 AM, Romain Manni-Bucau >
> wrote:
>
> > Hi guys,
> >
> > Just a quite summary of last fixes we worked on with Jonathan regarding
> the
> > security for ejbd/http client:
On Mon, Dec 5, 2016 at 11:17 AM, Romain Manni-Bucau
wrote:
> Hi guys,
>
> Just a quite summary of last fixes we worked on with Jonathan regarding the
> security for ejbd/http client:
>
> - we already have authorization parameter in the provider url for months
> (years now?).
Hi guys,
Just a quite summary of last fixes we worked on with Jonathan regarding the
security for ejbd/http client:
- we already have authorization parameter in the provider url for months
(years now?). This was not removed from the url so the user needed to
exclude some url from the access log
13/8/8 AndyG
> Added initial LegacyClientTest (which is currently a ripped
> RandomConnectionStrategyTest), but does the job. We can always add more to
> the test as new features are added.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD
Added initial LegacyClientTest (which is currently a ripped
RandomConnectionStrategyTest), but does the job. We can always add more to
the test as new features are added.
--
View this message in context:
http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664574.html
Sent from the OpenEJB Dev
.
> }else{
> ...legacy
> }
>
> I have tested this extensively on my boxes, but not sure how to write a
> 'simple' test? - Can you point me in the right direction for an existing
> test that I can hack?
>
>
>
>
>
> --
> View this message i
, but not sure how to write a
'simple' test? - Can you point me in the right direction for an existing
test that I can hack?
--
View this message in context:
http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664567.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
nything before I commit. I have a real world
> scenario to work on here and when I have it working I will commit.
>
> I may not be ready till tomorrow, so please hang on.
>
> Andy.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD
ssage in context:
http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664543.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
This would give us the 'minor'
>> version to query early in the request?
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664536.html
>> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>>
>
>
a server option, something like -
> AllowOldClients = false.
>
> Another option that I was looking at was the impact of changing the
> ProtocolMetaData OEJB version to 3.2 - This would give us the 'minor'
> version to query early in the request?
>
>
>
> --
>
ng at was the impact of changing the
ProtocolMetaData OEJB version to 3.2 - This would give us the 'minor'
version to query early in the request?
--
View this message in context:
http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664536.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
current version (3), but older servers still have code that basically
>> does 'if version == 2 do something', but should really have been 'if
>> version
>> >= 2 do something'.
>>
>> I still think it is a real requirement for older clients to be able to
>> talk
>> to a newer server though.
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664458.html
>> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>>
>
>
code that basically
> does 'if version == 2 do something', but should really have been 'if
> version
> >= 2 do something'.
>
> I still think it is a real requirement for older clients to be able to talk
> to a newer server though.
>
>
>
> --
>
27;if version == 2 do something', but should really have been 'if version
>= 2 do something'.
I still think it is a real requirement for older clients to be able to talk
to a newer server though.
--
View this message in context:
http://openejb.979440.n4.nabble.com/EJBD-tp4664447
t; 2013/8/1 AndyG
>
>> Older means ...possibly only as little as 4 weeks old snapshot. But I
>> guess
>> that 4.5.2 clients should still be able to look up ejbs on a 4.6 server
>> right?
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664455.html
>> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>>
>
>
2013/8/1 AndyG
> Older means ...possibly only as little as 4 weeks old snapshot. But I guess
> that 4.5.2 clients should still be able to look up ejbs on a 4.6 server
> right?
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664
Older means ...possibly only as little as 4 weeks old snapshot. But I guess
that 4.5.2 clients should still be able to look up ejbs on a 4.6 server
right?
--
View this message in context:
http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664455.html
Sent from the OpenEJB Dev mailing list
A bit of a pain to debug hopping from client to remote server.
--
View this message in context:
http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664453.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
; in Client.java:251
>
> Wrap stream with new BufferedReader(new InputStreamReader(in)).readLine()
>
> Which results in (less symbols):
>
> 3.1??org.apache.openejb.client.EJBMetaDataImpl?
>
> Looks like a serialized object.
>
>
>
> --
> View this messa
h new BufferedReader(new InputStreamReader(in)).readLine()
Which results in (less symbols):
3.1??org.apache.openejb.client.EJBMetaDataImpl?
Looks like a serialized object.
--
View this message in context:
http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664451.html
Sent from the OpenEJB Dev ma
edIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/8/1 AndyG
> Still have not got EJBD working for older clients. ProtocolMetaData gets a
> useless spec string back from the newer server.
>
> The order of write has changed on the server.
>
> Olde
Still have not got EJBD working for older clients. ProtocolMetaData gets a
useless spec string back from the newer server.
The order of write has changed on the server.
Older clients seem to be getting a serialized EJBMetaDataImpl rather than
the spec string.
Any ideas?
Andy.
--
View this
39 matches
Mail list logo
