Based on the scope you've described, I agree that this is almost a purely Java level task. I was under the impression that your scope was a little smaller than that.<br><br>With that in mind, you are really looking more for a solution entailing an entire permissions schema, at least to do it right and be flexible. That goes a little beyond where I can probably directly help - at least on a mailing list.
<br><br>I would handle this situation a couple different ways:<br><br> - I would see if someone else has already invented the wheel you need and posted the code either as a project or snippets online.<br> - Or, depending on the big picture, I would look into a content management solution either as an open source project or contact me off list as I work for a company that deals completely with content management and we may be able to do a full featured solution for you.
<br> <br>brad<br><br><div><span class="gmail_quote">On 6/27/06, <b class="gmail_sendername"><a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a></b> <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>
> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>When we last left our adventurers...<br><br>> Ok based on what you're telling me, you should be able to pass the data you
<br>> want want to send within that authenticated page.<br>><br>> For the time being though, let's go back to your apache configuration. Is<br>> it being used to serve regular content? In your example, you are serving a
<br>> text file. I know from previous posts, that you have other content being<br>> served as well. Is that content that you want tomcat to serve also being<br>> served via "normal" apache pages? If not, then just configure mod_jk to
<br>> serve those content types as well, then there is no more dual-app-server<br>> confusion. If not, then things get tricky.<br><br>Most of the static files are served by apache: .js, .jpg, .css. But the<br>files in /Data have special needs. They are static files. But a client can
<br>only access their files. And there are at least a few users per client.<br>And some users have access to some files and others do not.<br><br>><br>> If it's down to a pure java solution, then I'm really out of my element. My
<br>> best suggestion would be to hunt down some examples of this type of thing<br>> via google. I will ask some of the Java guys here about it and see if I can<br>> get something useful.<br><br>I do believe I'm down to having to use a pure Java solution. Since the
<br>authentication is not handled at any Tomcat layer. I have done much<br>searching and the common answer to this seems to be opening up the file<br>within java and streaming it back to the user. Which I am hoping to avoid
<br>because then I have to check every extension, and make sure to set the<br>correct contentType. And then if a new filetype is added for a different<br>client in the future (which is a very real possibility) then I will have
<br>to go back into the program and make sure that it is included.<br><br>So if anyone you work with has some suggestions that'd be awesome.<br><br>><br>> Normally the admin interface is at the url of your tomcat install /manager/
<br>> - of course this has to be enabled in your configuration xml files, but most<br>> default installs have it in some form, just check the configs.<br><br>Ok, found it. Thanks. I've just been editing the xml files by hand this
<br>whole time.<br><br>-Josh<br><br>><br>> On 6/27/06, <a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a> <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>> wrote:<br>>><br>>> The "Admin Interface" of which you speak alludes me. I'm just using
<br>>> plain-jane Tomcat from <a href="http://tomcat.apache.org">tomcat.apache.org</a>. I am no Java expert by any<br>>> means, so I think you are speaking of some concepts that I don't<br>>> understand. There may be a better way to handle logins, but I'm using a
<br>>> session-level (cookie) Bean. At the top of each of my .jsp pages is a<br>>> small function which checks the bean to make sure that they have access to<br>>> the page. If they do, then the page is displayed. If they do not then they
<br>>> are sent to the login page. With .jsp's this is very easy. I merely<br>>> "jsp:include" the relevant jsp which checks the login. But now I want to<br>>> serve up file /Data/Files/9/Batch/abc123.txt . Normally, apache would
<br>>> handle this request. But I need tomcat to make sure:<br>>><br>>> a.) This is client #9. And...<br>>> b.) This particular user (which belongs to client number 9) has access to<br>>> this particular file.
<br>>><br>>> So to do this I need to get to that session level bean. Which I don't know<br>>> any other way to do unless I get the request to a servlet or jsp of<br>>> somekind. And then I don't know how to get back to the file.
<br>>><br>>><br>>> When we last left our adventurers...<br>>><br>>> > Basically mod_jk, in its simplest form, will take a request bound for<br>>> port<br>>> > 80 and apache and look at the type of data it is requesting. Like .php
<br>>> gets<br>>> > passed to the php module, or .html gets handled natively by apache,<br>>> > something like .jsp will simply get forwarded on to Tomcat. Apache<br>>> isn't<br>>> > really doing anything at that point except for acting as a conduit so
<br>>> that<br>>> > both distinct servers can use port 80 simultaneously, which makes coding<br>>> > multi-language web apps a little simpler.<br>>> ><br>>> > Tomcat has a pretty extensive administration interface. Basically, when
<br>>> it<br>>> > gets set up, you do just enough dirty work on Tomcat to get the thing to<br>>> run<br>>> > and then configure everything else (permissions, database, settings,<br>>> etc.)
<br>>> > via the admin app. It's really though this app that you should be<br>>> directing<br>>> > your attention.<br>>> ><br>>> > Your application should have capability to access the allowed functions
<br>>> of<br>>> > the environment it's running within, which in this case is Tomcat. That<br>>> > includes your permissions and access. You shouldn't have to use<br>>> explicit<br>>> > filters and such just to access permission data being passed from the
<br>>> > session and handled by the application server.<br>>> ><br>>> > You may want to spend a little time grepping the tomcat docs and even do<br>>> > some searches over at the Sun website as they have their own spin off
<br>>> app<br>>> > server based on Tomcat, which is to say it is basically branded Tomcat.<br>>> ><br>>> > brad<br>>> ><br>>> > On 6/27/06, <a href="mailto:joshj@linuxmail.org">
joshj@linuxmail.org</a> <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>> wrote:<br>>> > ><br>>> > > When we last left our adventurers...<br>>> > ><br>>> > > > I would say that there should be no reason you couldn't do what you
<br>>> want<br>>> > > to<br>>> > > > natively within Tomcat. You shouldn't need more than a modicum of<br>>> java,<br>>> > > if<br>>> > > > any at all to do it. Tomcat should have some native handling of
<br>>> > > > authentication to it's services, which you can use in conjunction<br>>> with<br>>> > > your<br>>> > > > applications.<br>>> > > ><br>>> > > > The big thing to remember is that although you have Apache and
<br>>> Tomcat<br>>> > > linked<br>>> > > > using mod_jk, Tomcat is a standalone server, with it's own auth<br>>> > > mechanisms<br>>> > > > and capabilities. Mod_jk simply allows the java content to be
<br>>> passed<br>>> > > off to<br>>> > > > tomcat automagically through apache instead of having to directly<br>>> > > address<br>>> > > > the server over port 8080 or whereever you set it up at.
<br>>> > > ><br>>> > > > You probably know that, but just in case, I figured, I would<br>>> > > > expound<br>>> as<br>>> > > I<br>>> > > > know plenty of java developers that have very little clue about the
<br>>> > > workings<br>>> > > > of the app server and vice-versa.<br>>> > > ><br>>> > > > In short, it should be able to be done, and I would say to leverage<br>
>> > > Tomcat<br>>> > > > to do what you need to do.<br>>> > > ><br>>> > > > brad<br>>> > ><br>>> > > I just figured that since the trouble was put into making a mod_jk,
<br>>> and<br>>> > > not merely passing off the request to tomcat (mod_rewrite or proxy<br>>> style),<br>>> > > that maybe it did more than that. Like accepting requests back in<br>
>> > > some<br>>> > > way-shape-or-form.<br>>> > ><br>>> > > I'm attempting to use a Filter handle the request. Am I barking up<br>>> > > the<br>>> > > wrong tree? Or is this the way to go?
<br>>> > ><br>>> > > -Josh<br>>> > ><br>>> > > ><br>>> > > > On 6/27/06, <a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a> <<a href="mailto:joshj@linuxmail.org">
joshj@linuxmail.org</a>> wrote:<br>>> > > > ><br>>> > > > > It got a little out of hand but that was just some friendly<br>>> banter.<br>>> > > Merely<br>>> > > > > commenting on how sometimes someone here will ask a question and
<br>>> > > someone<br>>> > > > > else will recommend that they change their distro or platform. I<br>>> > > actually<br>>> > > > > completely agree with Brad. Enterprise (or "Enterprisey") is
<br>>> nothing<br>>> > > but<br>>> > > > > bullshit. Its all about a good language for the job at hand and<br>>> > > > > a<br>>> > > > > good
<br>>> > > > > design. And I try, God knows I try, but I hate Java for<br>>> > > webprogramming.<br>>> > > > ><br>>> > > > > So anyway, is it possible to verify someone's session and then
<br>>> dish<br>>> > > out<br>>> > > > > the file (using Apache/Tomcat)? And I don't care what kind of<br>>> file it<br>>> > > is.<br>>> > > > > Anything from txt to xml to pdf or jpg. I just don't want to use
<br>>> Java<br>>> > > to<br>>> > > > > 'stream' the file (even though that is the common answer I've<br>>> seen)<br>>> > > since<br>>> > > > > that is essentially duplicating code for something that Tomcat
<br>>> and<br>>> > > Apache<br>>> > > > > can already do.<br>>> > > > ><br>>> > > > > And my deepest apologies to any "Java lovers" (if there is such
<br>>> > > > > a<br>>> > > thing)<br>>> > > > > and "Enterprisey believers". I know not what I do.<br>>> > > > ><br>>> > > > > xo
<br>>> > > > > -Josh<br>>> > > > ><br>>> > > > > When we last left our adventurers...<br>>> > > > ><br>>> > > > > > Since this is all started and I'm feeling feisty this morning,
<br>>> I'll<br>>> > > add<br>>> > > > > my<br>>> > > > > > $.02 to the debate.<br>>> > > > > ><br>>> > > > > > I've supported and contributed to application devlopment using
<br>>> > > various<br>>> > > > > > languages and platforms. I can say with all confidence that<br>>> > > language<br>>> > > > > has<br>>> > > > > > only a small part to play with stability or
<br>>> > > > > enterprise-worthy-ness. It's<br>>> > > > > > about the coders and the project spec.<br>>> > > > > ><br>>> > > > > > Java is nice; it runs everywhere; and is OO by nature. Perl
<br>>> > > > > > is<br>>> > > > > > Perl<br>>> > > -<br>>> > > > > it<br>>> > > > > > does what it does and makes coffee with the right CPAN
<br>>> > > > > modules. However, in<br>>> > > > > > both of these cases, don't consider marketing propaganda,<br>>> corporate<br>>> > > > > dollars,
<br>>> > > > > > and press for reality.<br>>> > > > > ><br>>> > > > > > I've seen Java fail to accomplish the project's goals just as<br>>> > > quickly as
<br>>> > > > > if<br>>> > > > > > it was spec'd for Perl. On the flip side, I've seen PHP<br>>> > > > > > create<br>>> an<br>>> > > app
<br>>> > > > > for a<br>>> > > > > > quarter of the money and less than an 8th of the time of a<br>>> > > comparable<br>>> > > > > java<br>>> > > > > > solution. Of course, I've also seen some awsome things being
<br>>> > > developed<br>>> > > > > > using Java.<br>>> > > > > ><br>>> > > > > > My complaint with Java is the complexity involved in setting
<br>>> > > > > > up<br>>> an<br>>> > > > > efficient<br>>> > > > > > environment. Tomcat is not a simple app to setup and run -<br>>> > > especially
<br>>> > > > > if<br>>> > > > > > you are linking it to dynamically serve regular html or some<br>>> form<br>>> > > > > > of<br>>> > > > > > webscript pages like php.
<br>>> > > > > ><br>>> > > > > > Perl is also a beast. The fact that it has a loosely defined<br>>> form<br>>> > > > > without<br>>> > > > > > any real rigidity in its syntax makes for some very very very
<br>>> ugly<br>>> > > code.<br>>> > > > > > And don't get me started on CPAN.<br>>> > > > > ><br>>> > > > > > In all, there is no perfect language out there now. A good
<br>>> > > programmer<br>>> > > > > does<br>>> > > > > > the best job he / she can with the best tool for the job.<br>>> > > > > > They<br>
>> > > don't<br>>> > > > > simply<br>>> > > > > > do it because they can or because the marketing says its good<br>>> and<br>>> > > > > > "enterprise ready". But that rule should hold for all things
<br>>> IT.<br>>> > > > > ><br>>> > > > > ><br>>> > > > > ><br>>> > > > > > On 6/27/06, Pete Cummings <<a href="mailto:pete@linuxcowboy.com">
pete@linuxcowboy.com</a>> wrote:<br>>> > > > > > ><br>>> > > > > > > Websphere !!!!! That's great if you want to "port" your<br>>> freakin<br>>> > > job
<br>>> > > > > > > to<br>>> > > > > > > India! enterprise software =Asian concentration camps!!!<br>>> Stick<br>>> > > with<br>>> > > > > Open
<br>>> > > > > > > Source and live free (or die).<br>>> > > > > > ><br>>> > > > > > ><br>>> > > > > > > David J. Andruczyk wrote:
<br>>> > > > > > ><br>>> > > > > > > Use an enterprise application. i.e. don't ask your local<br>>> LUG,<br>>> > > ask<br>>> > > > > the
<br>>> > > > > > > enterprise vendors..<br>>> > > > > > ><br>>> > > > > > > The first one that pops into my head is IBM's websphere.<br>>> (only
<br>>> > > > > > > because<br>>> > > > > > > of the 40+ servers I support most run it with oracle for<br>>> > > > > > > all<br>>> > > their
<br>>> > > > > > > web<br>>> > > > > > > stuff) and this is a large worldwide "enterprise" level<br>>> site.<br>>> > > Aside<br>>> > > > > > > from that I don't know much about websphere. (I support the
<br>>> > > boxes,<br>>> > > > > > > not<br>>> > > > > > > the customer apps)<br>>> > > > > > ><br>>> > > > > > >
<br>>> > > > > > ><br>>> > > > > > > --- <a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a> wrote:<br>>> > > > > > ><br>>> > > > > > > Sing now while you can. Sure perl makes that little
<br>>> > > > > > > stuff<br>>> > > easier.<br>>> > > > > But<br>>> > > > > > > when<br>>> > > > > > > you're writing enterprise applications you can't use a toy
<br>>> like<br>>> > > that.<br>>> > > > > > > And<br>>> > > > > > > you want to talk about Scalable? I'd love to see you scale<br>>> your
<br>>> > > hippy<br>>> > > > > > ><br>>> > > > > > > programs across multiple servers!<br>>> > > > > > ><br>>> > > > > > > Love
<br>>> > > > > > > -Josh<br>>> > > > > > ><br>>> > > > > > > Well i'm sure you're java solution will be scalable<br>>> > > > > > > and
<br>>> > > > > enterprise<br>>> > > > > > > ready enough to allow you plenty of time to fix your tie<br>>> while<br>>> > > you<br>>> > > > > > > reassess your paradigm for a more proactive approach.
<br>>> > > > > > ><br>>> > > > > > > On 6/26/06, <a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a> <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org
</a>><br>>> > > > > > > <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>> wrote:<br>>> > > > > > ><br>>> > > > > > > Don't give me that "right tool for the job" malarky you
<br>>> > > > > > > freakin<br>>> > > > > > ><br>>> > > > > > > Perl<br>>> > > > > > ><br>>> > > > > > > hippy. Go back to the commune with all the other Perl,
<br>>> PHP,<br>>> > > > > > > and<br>>> > > > > > ><br>>> > > > > > > Python<br>>> > > > > > ><br>>> > > > > > > programmers.
<br>>> > > > > > ><br>>> > > > > > > _______________________________________________<br>>> > > > > > > nflug mailing list<br>>> > > > > > >
nflug@nflug.orghttp://www.nflug.org/mailman/listinfo/nflug<br>>> > > > > > ><br>>> > > > > > > _______________________________________________<br>>> > > > > > > nflug mailing list
<br>>> > > > > > > nflug@nflug.orghttp://www.nflug.org/mailman/listinfo/nflug<br>>> > > > > > ><br>>> > > > > > > Dave J. Andruczyk<br>>> > > > > > >
<br>>> > > > > > > __________________________________________________<br>>> > > > > > > Do You Yahoo!?<br>>> > > > > > > Tired of spam? Yahoo! Mail has the best spam protection
<br>>> around<br>>> > > > > > > <a href="http://mail.yahoo.com">http://mail.yahoo.com</a><br>>> > > > > > > _______________________________________________<br>
>> > > > > > > nflug mailing list<br>>> > > > > > > nflug@nflug.orghttp://www.nflug.org/mailman/listinfo/nflug<br>>> > > > > > ><br>>> > > > > > >
<br>>> > > > > > ><br>>> > > > > > > _______________________________________________<br>>> > > > > > > nflug mailing list<br>>> > > > > > >
<a href="mailto:nflug@nflug.org">nflug@nflug.org</a><br>>> > > > > > > <a href="http://www.nflug.org/mailman/listinfo/nflug">http://www.nflug.org/mailman/listinfo/nflug</a><br>>> > > > > > >
<br>>> > > > > > ><br>>> > > > > > ><br>>> > > > > ><br>>> >> >> _______________________________________________<br>>> > > > > nflug mailing list
<br>>> > > > > <a href="mailto:nflug@nflug.org">nflug@nflug.org</a><br>>> > > > > <a href="http://www.nflug.org/mailman/listinfo/nflug">http://www.nflug.org/mailman/listinfo/nflug
</a><br>>> > > > ><br>>> > > ><br>>> >> _______________________________________________<br>>> > > nflug mailing list<br>>> > > <a href="mailto:nflug@nflug.org">
nflug@nflug.org</a><br>>> > > <a href="http://www.nflug.org/mailman/listinfo/nflug">http://www.nflug.org/mailman/listinfo/nflug</a><br>>> > ><br>>> ><br>>> _______________________________________________
<br>>> nflug mailing list<br>>> <a href="mailto:nflug@nflug.org">nflug@nflug.org</a><br>>> <a href="http://www.nflug.org/mailman/listinfo/nflug">http://www.nflug.org/mailman/listinfo/nflug</a><br>>>
<br>><br>><br>_______________________________________________<br>nflug mailing list<br><a href="mailto:nflug@nflug.org">nflug@nflug.org</a><br><a href="http://www.nflug.org/mailman/listinfo/nflug">http://www.nflug.org/mailman/listinfo/nflug
</a><br></blockquote></div><br>