I'm building a new web app from scratch for a client.
The tools are JSF2, PrimeFaces, Spring3, GlassFish3, Hibernate.
I have a basic web app working fine. Now I have to put authentication in.
My first thought was to hack together a login form that sets a session variable and have a phase listener check for the session variable and redirect to "logged out" when the variable is invalid or too old. But that sounds like a total hack.
I've googled, but I don't really know where to start. What's the REAL way of doing authentication in my web app on my platform?
Can anyone help, or point me to a tutorial, or the relevant documentation?
Any help is greatly appreciated,
rh
The phaselistener you thought about is one of the solution in JSF. Another solution is Spring security. If you are not thinking about any of these, you can try Servlet filter
Related
For the first time, we are developing a new project that needs to support the browser (a website) and a mobile app built on react-native.
We have plenty of experience developing for the web, but little to no experience in the mobile app world.
We are now defining our API and trying to make it work for both platforms - This will be a basic JSON API, running on Flask. The API will have some public endpoints, and some protected ones as well (that require auth). We want a cross platform auth solution.
Typically, for the web, we have always relied on cookie based sessions (encrypted) that frameworks like Flask provide. We have been successfully using these in various scenarios: loading HTML templates directly from the web framework, or even when the frontend application runs on React (same domain + HttpOnly + secure cookies).
The introduction of react-native could potentially bring some new challenges, and some of our developers worry about not being able to continue to use our typical session based cookies - They are advocating to using something like JWT for authorization, for both the browser and app (and yes, I know that we can't compare sessions to token based auth).
I'm not a big fan of token based authorization (for a number of reasons, could entertain that conversation if anyone wants to waste some time...), and I can't seem to understand why we shouldn't stick to our normal encrypted "Cookie" value.
Here is how I imagine this could work, based on using the Flask cookie session:
A user hits /api/login with some credentials
The endpoint will validate the user and return back whatever response + the Set-Cookie header with a value of session=<encrypted string>
Any further requests from the browser/app would send back the cookie value again.
Essentially, nothing would change for typical browser implementations, this is how browsers work by default.
The react-native documentation mentions a few issues with cookie based authentication: https://reactnative.dev/docs/network#known-issues-with-fetch-and-cookie-based-authentication
From what I can gather (my knowledge is extremely limited on this subject), react-native might not always respect the Set-Cookie header. Which is OK - we would just have to make sure to send back the expected header with any further requests.
This, in theory, would fulfil our requirements.
I'm looking for feedback on my "solution", am I missing anything? Did I get HTTP completely wrong?
React Native actually provides networking similar to that of websites developed with basic JavaScript, which also supports cookie based authentication, however there are some serious caveats as mentioned in here
The following options are currently not working with fetch
redirect:manual
credentials:omit
Having same name headers on Android will result in only the latest one being present. A temporary solution can be found here:
https://github.com/facebook/react-native/issues/18837#issuecomment-398779994.
Cookie based authentication is currently unstable. You can view some of the issues raised here:
https://github.com/facebook/react-native/issues/23185
As a minimum on iOS, when redirected through a 302, if a Set-Cookie header is present, the cookie is not set properly. Since the redirect
cannot be handled manually this might cause a scenario where infinite
requests occur if the redirect is the result of an expired session.
Therefore, I would advise against using it as it is unstable and might give you a hard time dealing with it
I also suggest looking into frameworks that handle authentication for you, such as auth0
Hope you find this helpful :)
I have a problem integrating Vkontakte authentication using django-social-auth (https://github.com/omab/django-social-auth). I know that I have set everything right with AUTHENTICATION_BACKENDS as well as the API_KEYS and SECRETS for VKONTAKTE but still it does not work. I also have an authentication with Facebook and it works fine so I know that I am doing it right. Django-Social-Auth's documentation says about adding some JS script to make the authentication work but doesn't even provide some useful information about the script.
Can somebody provide some useful information about this? If you could provide some very nice tutorial on how to implement Vkontakte authentication using django-social-auth that would be great!
Thanks a lot guys! =)
If the url you're using is something like "http://localhost:8000/login/vkontakte/", try to change it to "http://localhost:8000/login/vkontakte-oauth2/".
I was investigating how to get status code 500 error messages to give me more information when these occur and happened upon the MSDN post about using the ClientHttp stack.. Which was all just so magical seeming until the application got deployed on the staging servers and it seems to completely fail now with authentication
I'm guessing this is due to the whole cookie issue as it relates to the ClientHttp stack...
I'm using RIA services and when the application starts it runs 3 or 4 RIA WCF service calls preloading data in the background and now with the new ClientHttpStack an authentication dialog pops up pretty much every single time a request is made. We're using Windows Authentication so before it would just make you authenticate in order to access the page serving the XAP file... But now you login with Win Auth and then all the subsequent calls repetitively ask for your credentials...
I'm assuming the only way I can fix this is by doing this
http://msdn.microsoft.com/en-us/library/dd920298(v=vs.95).aspx
And then possibly adding an endpoint behavior onto the DomainClient so that before requests are handled it tacks on the cookies...
I've tried doing this for a bit now and I'm not really succeeding... When I run the app in FF or Chrome it still pops up with a whole bunch of login boxes. So I'm just curious if I'm barking up the wrong tree or if I should continue trying to figure out where I'm not quite propagating the cookies through
If you are using the ClientHttp stack, you'll need a place to store your cookie client side, said a HttpCookieContainer. It's just a wcf behaviour to be inserted in the ClientHttp stack. Please, have a look at this post from Kile McClellan and see if it helps you.
I have a webpage in a Liferay 5.2.3 site, in order to view this page the user shoulde be logged in.
i tried JMeter for stress testing but i stopped after i had this issue here ("invalid authentication token"). What other tool i could use to do stress test without facing the authentication issue (with example of script if its available).
I had the same problem. I managed to log in and then when sending POST requests to the server I only received 403. What I have done is that I set the auth.token.check.enabled to false in the portal-ext.properties.
auth.token.check.enabled=false
But be careful. The Portal Authentication Token was implemented to prevent Cross Site Request forgery, as explained here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
On a production environment set the property back to true.
More about that on the liferay site: http://www.liferay.com/community/wiki/-/wiki/Main/Authentication+Token
Well I'm not sure but you could try Grinder, it supports jython as scripting language, although i dont have a working script example at the moment.
You can use JMeter but you have to use its proxy to record your actions (login included).
Please see JMeter proxy step by step
We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".