I am trying to run the tests using Zalenium but the browser is asking for the credentials, so I am providing the username and password manually.
Does anyone know how to handle browser authentication?
My project uses Specflow, C# and Selenium
There are several options
You can login with http://username:password#website.com/page
Automate login process at #BeforeMethod or #BeforeClass
Set cookies. Although I don't advise this method since it doesn't speed up automation much and there is quite a bit of work to do to implement it.
You could put your web application behind a proxy that automatically injects the basic auth credentials. I did this once for a client a few years back.
I'm pretty sure I used: https://github.com/adamfisk/LittleProxy with https://github.com/ganskef/LittleProxy-mitm
But I had to write some code intercept requests and inject basic auth headers. Although from memory it was pretty straight forward.
If you don't need https then you could probably use cntlm and then set the basic auth header by hand using this:
-r "HeaderName: value"
Add a header substitution. All such headers will be added/replaced
in the client's requests.
Related
In my Controller, which is build with using spring-boot, I've enable CORS only for my server and localhost whit this annotation:
#CrossOrigin(origins = {"http://localhost:8080", "https://www.somepage.com"}, maxAge = 3600)
This is working fine. But now I'm not sure, if it's also needed, to add basic authentication for the REST API. As far as I understood, the only call the REST API is accepting now, is my own server and localhost, and that's why, I think it's not needed. But I was not able to figure out, if this is a bad practice or not.
Do You recommend to use basic auth too for the REST API even when CORS is enabled?
No.
The Same Origin Policy is a feature built into browsers that prevents an attacker's JavaScript running on the attacker's website from reading the response to an HTTP request from the victim's browser to the targetted website.
This stops the attacker from stealing data from the targetted website using the credentials belonging to the victim.
(To some degree. There are other kinds of attacks.)
CORS is a tool that relaxes this rule so that when you to allow another site to access that data (either using the user's credentials or because it is just public data), it can.
Note that I said "a feature built into browsers". It isn't built into other tools.
An attacker can still make HTTP requests with their code, or tools like Postman and curl, or their own web browser.
Neither the Same Origin Policy nor CORS are substitutes for authentication and authorization.
CORS is a mechanism implemented in browsers and it will not prevent me to access your API with curl. Therefore, secure your API if you need it to stay secure.
I need to authenticate to JIRA using Okta via REST, how can I do that on ruby? It is possible? I never did that before, I just only want to get an attached file from a ticket in JIRA
It turns out that you can just send the JSESSIONID cookie from a logged-in user (such as yourself) to the REST API. You can get the cookie manually from the browser, or write a browser extension to get the cookie and then invoke your Ruby script with that cookie's value as a command-line argument. For Chrome, you could use Chrome Native Messaging for this.
You should be able to do it by setting up an Application Link to a ruby web application with 2-way OAuth, but this is quite complicated and heavyweight.
I would like to figure out a way to do it with just basic auth and no Application Link, but I haven't figured out how to yet.
We have a web-based application in which we are not requiring end users to login. The application uses Ajax to make calls to REST services hosted on the same server. Besides this application, we want to make sure that if any other applications / agents call the REST service they get denied.
What is the simplest way to secure a REST API like this? My guess is that we would include some sort of security token and make the call through HTTPS. However I'm not clear how the Ajax application would create/obtain/encrypt the token and generally what the lifecycle looks like.
I would rather do this outside of Spring Security or OAuth if possible. I have also read that sending username and password over SSL is enough for authentication. In this case, the app would have a "username" and password and it would send it with every request to the REST service. But how would it keep that information secret if the client is just HTML and javascript in the browser?
Thanks.
In general this is impossible. Someone could just do view source on your javascript, read the token, then do whatever they want.
https is not necessary here. For the token, probably the easiest is to set a cookie when they download the javascript from the server, then that cookie will also be transmitted with any AJAX requests.
This is not really secure - anyone can just see what the cookie is and use it, but it's the best you can do.
I just thought about writing a GWT app that just works as a client for a RESTful web service. The web service requires HTTP basic authentication for each call.
Since the client is not 'connected' with the server over a session, I have to remember the authentication credentials on the client side. I could do this within the GWT application, but with this, the client has to log in after every reload, which is not very beautiful. I also don't think it's a good idea to write this information to cookies, since everyone could read them.
So, who knows what I am looking for? :-)
Browsers save the username/password information for a given server/port/domain. So if the client has to login once (at least via the browser standard BASIC http dialog) it's preserved over the reloads.
I don't know if you can do that. Maybe forcing the user to navigate to a page inside the domain (or realm) and then using GWT...
I am desiging a RESTful Web Service (JBoss + RESTeasy). The UI programmer is writing an Ajax web app that will use it. The web app will be one HTML page with everything done in JavaScript. For security, all traffic goes through SSL.
Currently I'm using Basic authentication. The UI programmer can show a dialog to get a username and password and put "Authorization: Basic xxxxx" in the header. Unfortunately if the password is wrong, the ugly browser login dialog box comes up. Also there is no way for the user to log off. This is unacceptable.
There appears to be no way to intercept a 401 response to an XMLHttpRequest in any of the browsers we will use.
Form-based authentication won't work for us. We need an automatic logoff after some period of inactivity (the equivalent of a session timeout). We can't have the server suddenly return a login page when the client expects a JSON object.
JBoss offers four authentication strategies: BASIC, FORM, CLIENT-CERT and DIGEST. I think DIGEST has the same problem as BASIC. None of the four is what we want.
This web application will be the only client (for now) so there is no requirement to use BASIC. Is there any other authentication strategy I can install? For instance is there an implementation of WSSE UsernameToken I can use? (As described in Chapter 8 of the O'Reilly RESTful Web Services book.) The server would send "WSSE" instead of "Basic" in the WWW-Authenticate header and presumably the browser would ignore it and pass it right through.
I want to configure security where it belongs -- in the JBoss configuration files, not in my RESTful Web Service -- so I'm looking for an implementation I can just plug into JBoss.
The browser won't present the password dialog if it doesn't recognize the authentication scheme in the WWW-Authenticate header. Your best bet may be to continue using basic auth on the server while setting the header manually to something like "Basic/MyApp" for 401 responses.