Sorry, I have no idea where the 302 might originate from.
You would use the web form for the web client and BasicAuth for the requests
from the desktop client to the REST services since the desktop client is
probably not designed to handle web pages (string parsing is just sooo
awful). If you
Thanks for the info.
Yeah, I don't know what's up, but I just get the 302 "FOUND" status code, do
you have any idea why that would be? I will try to find out what gets passed
down, or see if there is some sort of error, but it seems to not pass any error
since it is "FOUND"| just not sure
If you cannot log in then something is wrong - did an exception get thrown or
some other hint show up as to what might be the cause?
A failed login attempt should return an HTTP 401 response so as to behave in
a way that most people would expect - but there is no technical reason for
it.
Basic
I'm really sorry it took me awhile to get back to you, I greatly appreciate
your time and patience with my questions.
I tried to do /** = authc and got an issue where my Status code changed from a
200 OK to a 302 "FOUND" but I couldn't log in with the changes.
I am able to log in just fine
If you configure the FormAuthenticationFilter to protect every HTTP request
in the [urls] section (/** = authc) then users would not be able to access
your login page without being authenticated. So, in order to let users
access the login page you specify it in the ini file which causes Shiro to
I'm sorry, I was just very confused overall, and my explanations weren't all
that good in the end.
Essentially, what I read in the docs and what I was using on the Client
originally, is that you have the ini file setup in some folder and then call it
in Java code by creating a factory and
I think I do not understand your questions - if Shiro has been already
initialized on the server for the web application, then, why do it a second
time? What do you mean with 'work with / access the ini file"? What do you
mean by "access the FormAuthenticationFilter"? You do not need to access it,
Thanks for the information. I understand that Shiro is not initialized on the
client, I think I am just not wording my question well, so sorry about that.
Essentially I want to know how to access the ini and Shiro properties from my
servlet in response to a request from the desktop-client.
The Shiro environment is only initialized on the server - *not* on the
clients. The clients need not know Shiro even exists, since they only use
regular HTTP requests with either Basic Authentication (desktop client
[REST]) or Form Authentication (Browser [HTTP session]). The server is
initialized
Firstly, I want to say thanks again so much for all of the time/effort putting
into answering my questions, I appreciate it very much.
Second, I want to apologize for not getting back to you in almost 2 weeks.
Recently a family member became extremely ill, so I haven't been able to get to
a
The subject is a kind of proxy to the underlying SecurityManager meaning some
methods of Subject actually just trigger calls to the SecurityManager which
in turn triggers methods on the configured realms.
You would use subject.isAuthenticated() on the server's HTTP interface to
determine whether
I believe JSPs offer no benefit - they have been replaced by JSF within JEE.
You can use servlets without JSP or JSF, but if you do use JSP or JSF you
will need an application server like Wildfly or Glassfish or have to include
the required components into Tomcat yourselves.
You do not check
Sorry for the double email, but hit reply too fast. I was looking at your
comment about "not sending" the Subject, but isn't the Subject created based on
the user's machine? It seems that when you get the security info and then
getSubject that it will get a Subject fo the current machine. Is
Thanks for the information, I appreciate your time as does my friend.
That's interesting you don't need a JSP page, I thought that was needed in
order to work with Shiro, but I guess that's just normal if you're going to
make a JAva application with Shiro.
I believe his Desktop Client is
All browsers handle sessions for you, so on the web client you need *not*
check sessions but instead just do form authentication:
https://shiro.apache.org/webapp-tutorial.html#step3 (you need not use a JSP
page, any POST operation that results in the same HTTP request will work)
And then the
15 matches
Mail list logo
