Rob Spoor

Sheriff
+ Follow
since Oct 27, 2005
Rob likes ...
Chrome Eclipse IDE Java Spring Ubuntu VI Editor Windows
Forum Moderator
Rob Spoor currently moderates these forums:
Cows and Likes
Cows
Total received
105
In last 30 days
0
Total given
43
Likes
Total received
1552
Received in last 30 days
2
Total given
2331
Given in last 30 days
4
Forums and Threads

Recent posts by Rob Spoor

Simon McNamara wrote:Jython is not an option for me.


Can you tell us why not?
1 day ago
Try adding a RewriteRule before the ProxyPass (don't forget to turn on the RewriteEngine).

And welcome to the Ranch!
2 weeks ago
Why don't you use request.getParameterValues? That way you don't have to do any custom splitting. For instance:
3 weeks ago
So your module JAR files are in the jar folder, right? So why don't you add that to your module path instead of the current directory (.)? Because the current directory can only work if that's the directory where your module JAR files are located.
3 weeks ago

Tim Holloway wrote:One is the so-called "hard" link. I'm not sure Windows supports this.


It does: https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions

Anyway, I think the problem here is that the shortcut is located inside the JAR file. The file system cannot execute anything inside a JAR file, which is little more than a ZIP file. This isn't a limitation of the JAR file but of the file system. If you would like to execute it, you need to unpack it somewhere first.


On a side note, if you wish to "run" a file, such as a shortcut, you should consider using java.awt.Desktop:

To be on the safe side you can first check if Desktop.isDesktopSupported() returns true.
3 weeks ago

Tim Holloway wrote:

Rob Spoor wrote:I was waiting for Tim H's post ever since I read the initial post.



What? Just because I'm obsessed with it? I'd feel guilty except that it's admitted by almost anyone who's worked for any length of time with webapps that when users (or the shop's resident, um, genius) designs a "security system", the results almost invariably have all the durability of wet tissue paper.


I didn't mean you specifically posting it, I meant someone mentioning web security. That should have been one of the first answers. It's no surprise it comes from you though

Rob Spoor wrote:The only drawback is that part of the mechanism is container specific - Tomcat, JBoss, GlassFish and other containers could all do the actual user authentication + role mapping differently. You'd need to check the container documentation on how to do this exactly.



The only part of the mechanism that's container specific is the configuration of the Realm for the container. The webapp requires absolutely no changes for security regardless of what webapp server you deploy it to. Furthermore, changing the Realm itself doesn't require webapp modification. The same app that runs with JDBC authentication and authorization will work equally well under LDAP or XML file Realms or even a site-wide single-signon.


I actually meant that. There may be some internal mapping from container specific role to web.xml role (I've had to do this with WebLogic), and the way the user credentials are stored may be different (users.properties file vs web interface), but that should not be a concern of the application. It has its own roles to worry about (defined in web.xml), and authenticating should simply be delegated to the container (either through the web.xml defined authentication method or by using HttpServletRequest.login).
1 month ago
I was waiting for Tim H's post ever since I read the initial post. See https://javaee.github.io/tutorial/security-webtier002.html for a bit more information. The only drawback is that part of the mechanism is container specific - Tomcat, JBoss, GlassFish and other containers could all do the actual user authentication + role mapping differently. You'd need to check the container documentation on how to do this exactly.
1 month ago
You can use http://www.asciitable.com/ to see the numeric values of the first 127 characters. Apart from TAB (\t, 9), LF (\n, 10) and CR (\r, 13), nothing before space (32) is of much interest for most people.
1 month ago
Stephan, great post, but I disagree with one thing. You use LinkedHashSet and LinkedHashMap as defaults. I would prefer HashSet and HashMap unless you need a fixed order. If you don't need it (and I hardly ever really need it apart from getting predictable test results), for instance because you use a Map just for lookups, a HashMap is a (slightly) better choice.
1 month ago

Ron McLeod wrote:The only issue I have now is the warning with my class which extends AnnotationLiterial: The annotation type BasestationTypeQualifier should not be used as a superinterface for BasestationTypeLiteral - basically saying that one should not implement an annotation.  The followed the example in the javadoc, but it would also have this same warning.  I've seen a number of people with this same problem, but haven't seen any resolution.


Ah yes, that nice little warning. I have one project that is just about warning free, apart from that one. The warning makes sense from a JSE perspective, as you shouldn't supply your own annotation implementations. For JEE however this is a good example of a valid use case.

There is possibly one work-around I found - provide a utility class for each annotation so you can use reflection to retrieve the annotation. That's even uglier though.
At work we've once done this, and it was indeed solved with qualifiers. We had a qualifier annotation with a specific value which we used to annotate our beans that implemented an interface. We then injected an Instance of the interface. We then used its select method to find the correct bean implementation(s). AnnotationLiteral can be used to provide the annotation to use with the select method.
You have two options:

1) Remove all the Git properties. If you don't need them there's no need for them.

2) Include plugin the following plugin:

This will actually provide the Git properties you're using. (There is a version 4.0.0 but I haven't tried that one yet.)
1 month ago
From ServletContext.getRequestDispatcher:

The pathname must begin with a / and is interpreted as relative to the current context root.


On the other hand, ServletRequest.getRequestDispatcher supports relative paths:

The pathname specified may be relative, although it cannot extend outside the current servlet context. If the path begins with a "/" it is interpreted as relative to the current context root. This method returns null if the servlet container cannot return a RequestDispatcher.

The difference between this method and ServletContext.getRequestDispatcher(java.lang.String) is that this method can take a relative path.

1 month ago
JSP