[jcifs] RE: jcifs digest, Vol 1 #519 - 3 msgs
Michael B. Allen
miallen at eskimo.com
Fri Oct 25 05:06:32 EST 2002
On Thu, 24 Oct 2002 14:21:11 -0400
"Sujit Jagdev" <sujit.jagdev at casero.com> wrote:
> 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
Look at laddr and baddr properties. All jCIFS properties are described in
fair detail on the Overview page of the API documentation (scroll down).
>
> -----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.
>
--
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not
yet been conceived.
More information about the jcifs
mailing list