[jcifs] RE: jcifs digest, Vol 1 #519 - 3 msgs
Sujit Jagdev
sujit.jagdev at casero.com
Fri Oct 25 04:21:11 EST 2002
I have got a question about scanning the local interface i.e. eth0.
If I have a machine that has two network jacks and one of them points to
the WAN and the other to the LAN.
For instance, if I have a box that is connected to the internet via one
NIC and the other is pointing to a local network ( someone's LAN ) How
do I get jcifs scan the LAN ( eth0 ) as opposed to eth1.
Thanks
Sujit
-----Original Message-----
From: jcifs-request at lists.samba.org
[mailto:jcifs-request at lists.samba.org]
Sent: Thursday, October 24, 2002 12:00 PM
To: jcifs at lists.samba.org
Subject: jcifs digest, Vol 1 #519 - 3 msgs
Send jcifs mailing list submissions to
jcifs at lists.samba.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.samba.org/listinfo/jcifs
or, via email, send a message with subject or body 'help' to
jcifs-request at lists.samba.org
You can reach the person managing the list at
jcifs-admin at lists.samba.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of jcifs digest..."
Today's Topics:
1. java.net.MalformedURLException: unknown protocol: smb
(Mats.Svensson at astrazeneca.com)
2. Re: Alternative to jcifs.http.NtlmHttpFilter (Michael Piscatello)
3. Re: Alternative to jcifs.http.NtlmHttpFilter (eglass1 at attbi.com)
--__--__--
Message: 1
From: Mats.Svensson at astrazeneca.com
To: jcifs at samba.org
Date: Thu, 24 Oct 2002 11:39:54 +0200
Subject: [jcifs] java.net.MalformedURLException: unknown protocol: smb
Hi!
I try to use the NetworkExplorer servlet on:
jcifs 0705b
resin 215
jdk 141_01
w2k sp3
but I keep getting the exception included below.
1) I can't find any documentation (other than the source) on
how the URL (PathInfo) is supposed to be used, I guess it is
http://servletContainerHost/NetworkExplorer/someHostIwantToExplore/Share
java.net.MalformedURLException: unknown protocol: smb
at java.net.URL.<init>(URL.java:586)
at java.net.URL.<init>(URL.java:476)
at java.net.URL.<init>(URL.java:425)
at jcifs.smb.SmbFile.<init>(SmbFile.java:401)
at jcifs.http.NetworkExplorer.doGet(NetworkExplorer.java:421)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:126)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
at
com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.ja
va:9
6)
at
com.caucho.server.http.Invocation.service(Invocation.java:312)
at
com.caucho.server.http.CacheInvocation.service(CacheInvocation.java:135)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:221)
at
com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:163
)
at com.caucho.server.TcpConnection.run(TcpConnection.java:137)
at java.lang.Thread.run(Thread.java:536)
web.xml:
<web-app>
<classpath id='WEB-INF/lib/jcifs-0.7.0b5.jar'/>
<servlet>
<servlet-name>NetworkExplorer</servlet-name>
<servlet-class>jcifs.http.NetworkExplorer</servlet-class>
<init-param>
<param-name>jcifs.smb.client.domain</param-name>
<param-value>ADOMAIN</param-value>
</init-param>
<init-param>
<param-name>jcifs.netbios.wins</param-name>
<param-value>192.168.1.32</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>NetworkExplorer</servlet-name>
<url-pattern>/NetworkExplorer/*</url-pattern>
</servlet-mapping>
</web-app>
--__--__--
Message: 2
Date: Thu, 24 Oct 2002 07:19:01 -0400
Subject: Re: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
From: Michael Piscatello <mpiscatello at directvinternet.com>
To: "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com>,
Eric Glass <eglass1 at attbi.com>
Cc: <jcifs at lists.samba.org>
When using the
NtlmPasswordAuthentication ntlm =
> (NtlmPasswordAuthentication)req.getSession().getAttribute(
"NtlmHttpAuth" );
>
I am getting a null when I look for NtlmHttpAuth in the session. Where
can
I look to see what is happening?
Thanx
Mike
On 10/22/02 8:17 PM, "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com>
wrote:
> The pop-up appeared? So you modified it to send the additional 401
> Unauthorized
> / WWW-Authenticate: NTLM? Make sure it's really authenticating OK by
> retrieving
> the NtlmPasswordAuthentication object like:
>
> NtlmPasswordAuthentication ntlm =
> (NtlmPasswordAuthentication)req.getSession().getAttribute(
"NtlmHttpAuth" );
>
> That will also give you access to the username and domain.
>
>> -----Original Message-----
>> From: Michael Piscatello [SMTP:mpiscatello at directvinternet.com]
>> Sent: Tuesday, October 22, 2002 8:01 PM
>> To: Eric Glass
>> Cc: jcifs at lists.samba.org
>> Subject: Re: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
>>
>> Eric, Mike,
>>
>> I tested the servlet against unauthenticated clients and the pop-up
>> appeared, took the credentials, and authenticated the user! This
testing was
>> done in a WAS 4.0.2 environment with both PC and Mac clients using
IE.
>>
>> Mike
>>
>> On 10/22/02 7:57 PM, "Eric Glass" <eglass1 at attbi.com> wrote:
>>
>>> On Tue, 2002-10-22 at 19:17, Allen, Michael B (RSCH) wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: eglass1 at attbi.com [SMTP:eglass1 at attbi.com]
>>>>> Sent: Tuesday, October 22, 2002 3:30 AM
>>>>> To: Allen, Michael B (RSCH)
>>>>> Cc: 'Michael Piscatello'; jcifs at lists.samba.org
>>>>> Subject: RE: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
>>>>>
>>>>> I thought about this as well -- one thing that might be
>>>>> useful would be to include the HttpServletRequestWrapper
>>>>> in the filter (to provide getPrincipal(), getRemoteUser
>>>>> (), etc.),
>>>>>
>>>> Not sure what you mean by this. Do you mean include the
>>>> HttpServletRequestWrapper class with the jCIFS package?
>>>>
>>>
>>> I just meant a wrapper subclass to provide the principal -- I see
this
>>> made it into 0.7.0b5 as "NtlmHttpServletRequest".
>>>
>>>>> but then set the "NtlmHttpFilter" session
>>>>> flag to the principal name (i.e., 'DOMAIN\user') instead
>>>>> of just the string "1". That way, it provides a quick
>>>>> and dirty means of obtaining that information under 2.2-.
>>>>>
>>>> Actually I did change the attribute name to NtlmHttpAuth
>>>> and I put the NtlmPasswordAuthentication object in the
>>>> session instead of "1". I realize this was the sort of thing
>>>> that got me in trouble the last time but take a look. I think
>>>> you'll agree it should work just fine.
>>>
>>> Yes, I think that most of the issues stemmed from having the
negotiation
>>> rely on the session; with the new stuff, the worst case (if the
client
>>> can't accept the session) is just that the authentication gets
>>> renegotiated each time. This shouldn't be an issue, since no state
is
>>> maintained during the authentication.
>>>
>>>> retrive that. It now implements java.security.Principal so I
>>>> need to put that in the session so I can pass it to the
>>>> NtlmHttpServletRequest (a.k.a your NtlmRequest). Doing
>>>> this avoids performing NTLM SSP with each and every
>>>> request which is noticably slower and provides the
>>>> getRemoteUser functionality at the same time.
>>>>
>>>
>>> I liked your take on having NtlmPasswordAuthentication implement
>>> Principal, by the way -- I thought that was clever. I haven't had a
>>> chance to do any real testing yet, but from what I've seen so far it
>>> looks great.
>>>
>>> Eric
>>>
>>>
>>
>
>
--__--__--
Message: 3
From: eglass1 at attbi.com
To: Michael Piscatello <mpiscatello at directvinternet.com>
Cc: "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com>,
<jcifs at lists.samba.org>
Subject: Re: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
Date: Thu, 24 Oct 2002 14:09:11 +0000
Hmmm... there are a couple of possibilities I could
think of.
First, try retrieving "ntlmdomain" and "ntlmuser" from
the session. If these two are there, but NtlmHttpAuth
isn't, then the issue may be the fact that
NtlmPasswordAuthentication is not Serializable;
according to the servlet spec, a session is only
REQUIRED to accept Serializable objects. It MAY accept
other objects, and although it MAY throw an
IllegalArgumentException for unsupported entries, it
isn't required -- it is conceivable that your container
is simply ignoring the attribute (although technically
it IS supposed to throw an exception if it is incapable
of migrating the object between VMs). You should be
able to test this by simply adding Serializable to the
implements list of NtlmPasswordAuthentication and seeing
if it works. For maximum compatibility, this should
probably be added anyways.
If NONE of the attributes are showing up, it may be that
the service method of HttpServlet is removing them
(during the call to super.service) or otherwise
monkeying around with the session (although I don't
believe it is supposed to do anything except dispatch
the method-specific calls). The solution in this case
would be to remove the call to super.service and
manually dispatch the doXXX methods, instead of relying
on HttpServlet to do so, like:
if (request.getMethod().equalsIgnoreCase("GET")) {
doGet(request, response);
}
and so on for each of the doXXX methods.
Or it could be something else completely. In any case,
let me know what you find... I don't have access to a
testing environment readily available right now, but
when I get a chance I will tool around with it and see
what I can determine.
Eric
> When using the
>
> NtlmPasswordAuthentication ntlm =
> > (NtlmPasswordAuthentication)req.getSession().getAttribute(
"NtlmHttpAuth" );
> >
>
> I am getting a null when I look for NtlmHttpAuth in the session.
Where can
> I look to see what is happening?
>
> Thanx
>
> Mike
>
>
> On 10/22/02 8:17 PM, "Allen, Michael B (RSCH)"
<Michael_B_Allen at ml.com>
> wrote:
>
> > The pop-up appeared? So you modified it to send the additional 401
> > Unauthorized
> > / WWW-Authenticate: NTLM? Make sure it's really authenticating OK by
> > retrieving
> > the NtlmPasswordAuthentication object like:
> >
> > NtlmPasswordAuthentication ntlm =
> > (NtlmPasswordAuthentication)req.getSession().getAttribute(
"NtlmHttpAuth" );
> >
> > That will also give you access to the username and domain.
> >
> >> -----Original Message-----
> >> From: Michael Piscatello [SMTP:mpiscatello at directvinternet.com]
> >> Sent: Tuesday, October 22, 2002 8:01 PM
> >> To: Eric Glass
> >> Cc: jcifs at lists.samba.org
> >> Subject: Re: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
> >>
> >> Eric, Mike,
> >>
> >> I tested the servlet against unauthenticated clients and the pop-up
> >> appeared, took the credentials, and authenticated the user! This
testing was
> >> done in a WAS 4.0.2 environment with both PC and Mac clients using
IE.
> >>
> >> Mike
> >>
> >> On 10/22/02 7:57 PM, "Eric Glass" <eglass1 at attbi.com> wrote:
> >>
> >>> On Tue, 2002-10-22 at 19:17, Allen, Michael B (RSCH) wrote:
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: eglass1 at attbi.com [SMTP:eglass1 at attbi.com]
> >>>>> Sent: Tuesday, October 22, 2002 3:30 AM
> >>>>> To: Allen, Michael B (RSCH)
> >>>>> Cc: 'Michael Piscatello'; jcifs at lists.samba.org
> >>>>> Subject: RE: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
> >>>>>
> >>>>> I thought about this as well -- one thing that might be
> >>>>> useful would be to include the HttpServletRequestWrapper
> >>>>> in the filter (to provide getPrincipal(), getRemoteUser
> >>>>> (), etc.),
> >>>>>
> >>>> Not sure what you mean by this. Do you mean include the
> >>>> HttpServletRequestWrapper class with the jCIFS package?
> >>>>
> >>>
> >>> I just meant a wrapper subclass to provide the principal -- I see
this
> >>> made it into 0.7.0b5 as "NtlmHttpServletRequest".
> >>>
> >>>>> but then set the "NtlmHttpFilter" session
> >>>>> flag to the principal name (i.e., 'DOMAIN\user') instead
> >>>>> of just the string "1". That way, it provides a quick
> >>>>> and dirty means of obtaining that information under 2.2-.
> >>>>>
> >>>> Actually I did change the attribute name to NtlmHttpAuth
> >>>> and I put the NtlmPasswordAuthentication object in the
> >>>> session instead of "1". I realize this was the sort of thing
> >>>> that got me in trouble the last time but take a look. I think
> >>>> you'll agree it should work just fine.
> >>>
> >>> Yes, I think that most of the issues stemmed from having the
negotiation
> >>> rely on the session; with the new stuff, the worst case (if the
client
> >>> can't accept the session) is just that the authentication gets
> >>> renegotiated each time. This shouldn't be an issue, since no
state is
> >>> maintained during the authentication.
> >>>
> >>>> retrive that. It now implements java.security.Principal so I
> >>>> need to put that in the session so I can pass it to the
> >>>> NtlmHttpServletRequest (a.k.a your NtlmRequest). Doing
> >>>> this avoids performing NTLM SSP with each and every
> >>>> request which is noticably slower and provides the
> >>>> getRemoteUser functionality at the same time.
> >>>>
> >>>
> >>> I liked your take on having NtlmPasswordAuthentication implement
> >>> Principal, by the way -- I thought that was clever. I haven't had
a
> >>> chance to do any real testing yet, but from what I've seen so far
it
> >>> looks great.
> >>>
> >>> Eric
> >>>
> >>>
> >>
> >
> >
>
--__--__--
_______________________________________________
jcifs mailing list
jcifs at lists.samba.org
http://lists.samba.org/listinfo/jcifs
End of jcifs Digest
-----
The information contained in this message is proprietary of Casero Inc.,
protected from disclosure, and may be privileged. The information is
intended to be conveyed only to the designated recipient(s) of the
message. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, use, distribution or
copying of this communication is strictly prohibited and may be
unlawful. If you have received this communication in error, please
notify us immediately by replying to the message and deleting it from
your computer. Thank you.
More information about the jcifs
mailing list