The import javax.servlet cannot be resolved
Tomcat 9.0.53 Windows Server 2019 Standard version 1809 OpenJDK jdk-11.0.8.10-hotspot I have a JSP/JavaBean webapp. I deployed all of the class files into the webapp's classes subdirectory (no WAR file) and the external JAR files are in the webapp's lib directory. Of course, the JSPs are in the webapp's context root. I try running the webapp from localhost:8080/[appname]/LoginPage.jsp and I get the subject error with the stacktrace pointing at my JavaBean line: import javax.servlet.http.HttpServletRequest I've tried copying *servlet-api.jar* from the tomcat lib directory into my webapp\lib directory and I've tried putting *javaee-api-8.0.jar* into my webapp\lib directory and neither helped. Any insights would be appreciated. Dick
Re: Specifying a Custom Authenticator Class
I really don't care whether it's called Basic, Malcolm, RollYourOwn, or
whatever. I was just emulating techniques I've had to implement as a
client for credit card gateways and other services in the past that all
use BASIC prefix with their own token definition. I can easily rename
the Authorization header prefix or not even call the header
"Authorization". The main thing is there is a base64 token associated
with it. Our application has a mobile app with a rather large REST
api. The security requirements of this product far exceed id:pw
authentication. We have additional pre-shared keys, timestamps, and
other undisclosed data built into the raw token that is converted to
base64 and added to the header. This REST api authentication is
implemented and working without problems.
Here's the situation. There is a certain amount of user data that is
not yet displayable in the current version of the mobile app. We have a
couple of links to the main web site where the user can view the
remainder of their data. I don't want to throw up a login screen when a
user, who is already logged into the app, clicks the link to view the
data that is on the web site. But I also want to maintain the same
level of security as we have with REST to establish the session. The
server already knows how to authenticate from the REST api tokens. I
simply want to use the same token and the same auth code to "login" the
user and create a session just like I can do with request.login( id, pw
), but using my own authentication code from the auth header token.
An earlier post suggested I just implement a CredentialHandler, which
would be great. But it looked like the credential handler is given
"id/pw" extracted from the base64. Or will it actually return whatever
it finds in the base64 token? "A:B:C:D:E:F" instead of "id:pw"? If it
does just return the base64 decoded string, that would definitely make
it much simpler to implement, but then that would still require I use
"Basic" as the prefix in order for all of the normal tomcat auth header
processing to work to send to my custom credential handler, correct? I
realize that renaming the header prefix to "Malcolm" or whatever would
be more architecturally pure. But how much more code is involved to
get the same result if my authorization header prefix is now "Malcolm"
instead of "Basic"?
Just exploring my options.
Thanks for the discussion. It's helping me a lot.
Jerry
On 10/4/2021 8:49 AM, Christopher Schultz wrote:
Michael,
On 10/3/21 11:58, Michael Osipov wrote:
Am 2021-10-02 um 02:48 schrieb Jerry Malcolm:
I need to write a custom BasicAuthenticator class to decode a
specialized encoding of the authToken. I have been scouring google
for info. I found one post where the answer included the statement:
This would clearly violate Basic auth scheme and the according RFC. I
highly recommend against. Don't abuse Basic. Create your own
scheme/header and solve your problem with it.
This is a very good point.
Instead of:
Authorization: Basic [base64stuff]
Using "Bearer" might be a better choice, though that is also covered
by a specific RFC and might be confusing to overload that token
("Bearer") for another purpose.
You could just do:
Authorization: Malcolms [token]
If you are going to write a custom authenticator, anyway. You'll need
to have a custom client, of course, but you will already have that
kind of thing because no standard HTTP client would format your
authentication tokens in this way.
Another dumb question: why use your own custom stuff instead of the
standard(s)?
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 9.0.54 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.54. Apache Tomcat 9 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 9.0.54 is a bugfix and feature release. The notable changes compared to 9.0.53 include: - Further robustness improvements to HTTP/2 flow control window management. - Improvements to the DataSourceUserDatabase. - Fix an issue that caused some Servlet non-blocking API reads of the HTTP request body to incorrectly use blocking IO. Along with lots of other bug fixes and improvements. Please refer to the change log for the complete list of changes: https://tomcat.apache.org/tomcat-9.0-doc/changelog.html Downloads: https://tomcat.apache.org/download-90.cgi Migration guides from Apache Tomcat 7.x and 8.x: https://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 10.0.12 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.0.12. This release is targeted at Jakarta EE 9. Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. The notable changes compared to 10.0.11 include: - Further robustness improvements to HTTP/2 flow control window management - Improvements to the DataSourceUserDatabase - Fix an issue that caused some Servlet non-blocking API reads of the HTTP request body to incorrectly use blocking IO. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 10.1.0-M6 (alpha) available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.1.0-M6 (alpha). Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. Apache Tomcat 10.1.0-M6 is a milestone release of the 10.1.x branch and has been made to provide users with early access to the new features in Apache Tomcat 10.1.x so that they may provide feedback. The notable changes compared to 10.1.0-M5 include: - Servlet API updates for Servlet 6 including removal of all deprecated code, updated schemas and a new API for connection and request IDs. - EL API updates for EL 5.0 including deprecation of the use of FeatureDescriptor, improvements to BeanELResolver and the addition of MethodReference - Further robustness improvements to HTTP/2 flow control window management Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.1-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Specifying a Custom Authenticator Class
Michael,
On 10/3/21 11:58, Michael Osipov wrote:
Am 2021-10-02 um 02:48 schrieb Jerry Malcolm:
I need to write a custom BasicAuthenticator class to decode a
specialized encoding of the authToken. I have been scouring google
for info. I found one post where the answer included the statement:
This would clearly violate Basic auth scheme and the according RFC. I
highly recommend against. Don't abuse Basic. Create your own
scheme/header and solve your problem with it.
This is a very good point.
Instead of:
Authorization: Basic [base64stuff]
Using "Bearer" might be a better choice, though that is also covered by
a specific RFC and might be confusing to overload that token ("Bearer")
for another purpose.
You could just do:
Authorization: Malcolms [token]
If you are going to write a custom authenticator, anyway. You'll need to
have a custom client, of course, but you will already have that kind of
thing because no standard HTTP client would format your authentication
tokens in this way.
Another dumb question: why use your own custom stuff instead of the
standard(s)?
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
