Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
I'm trying to convince Firefox 3.0.14 to send a Kerberos token. I have configured the service correctly and IE will send a Kerberos token (i.e. starting YI..), but after adding the hostname to the network.negotiate-auth.trusted-uris and network.negotiate-auth.delegation-uris settings in about:config, Firefox only sends an NTLM token. Here's the (cut down) output from Live Headers:
to server ->
GET /testsso.jsp HTTP/1.1
<- from server
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Negotiate
to server ->
GET /testsso.jsp HTTP/1.1
Authorization: Negotiate TlxxxxxxxxQ=
<- from server
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Negotiate
The server is only interested in a Kerberos token, i.e. one starting in YI, so issues the Unauthorized on the second request, at which point Firefox gives up.
I'm using Windows 2003. Any thoughts?
J
Kerberos is disabled on a default firefox.
You can enable it, check out the guide here:
http://grolmsnet.de/kerbtut/firefox.html
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 19 hours ago.
Improve this question
I am using Spring Boot and I have CORS enabled in my Spring Security config (5.8.1) configuration:
protected SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http.cors().and().csrf().disable();
We have setup a login success handler for our REST requests which redirects after succssful login
Authentication authentication) throws IOException {
String redirectUrl = applicationPropertyReader.getRedirectUrl() + "/tiles";
response.sendRedirect(redirectUrl);
}
Please see also my Dev Tools Network Screenshot below:
Chrome Network Screenshot
Request works fine:
https://myDomain.de
redirect to https://myDomain.de/tiles (OK - 200)
Request fails:
https://www.myDomain.de
redirect to https://myDomain.de/tiles (fails with 401)
in 2), after setting up CORS the preflight "OPTIONS" is returned OK (200) but the actual GET fails with HTTP 401.
While tackeling my general CORS preflight issue before, I think I read something about "the redirect is to fast" on stackoverflow. But now since preflight works, I do not find that question again :-(.
Your help is appreciated. Thanks!
I'm using gssapi/Kerberos authentication in my web application, and I want single sign on via the browser.
The problem is, Firefox sends an initial request to the server with no authentication, and receives a 401. But it includes a keep-alive header:
Connection: keep-alive
If the server respects this keep-alive request, and returns a WWW-Authenticate header, then Firefox behaves correctly and sends the local user's Kerberos credentials, and all is well.
But, if the server doesn't keep the connection alive, Firefox will not send another request with the credentials, even though the response has the WWW-Authenticate header.
This is a problem because I'm using Django, and Django doesn't support the keep-alive protocol.
Is there a way to make Firefox negotiate without the keep-alive? In the RFC that defines the Negotiate extension, there's nothing about requiring that the same connection be re-used.
Alternatively, is there a way to make Firefofx preemptively send the credentials on the first request? This is explicitly allowed in the RFC.
That header is HTTP 1.0, wake up, fast-forward 15 years and your problems will go away. Firefox works very well with SPNEGO.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 4 years ago.
Improve this question
I've been facing this issue for several days now. I'm trying to make a call to my API (api.mywebsite.com) from my website (mywebsite.com), and it works fine until I try to pass the Authorization header. At that point, it's not a simple request anymore, but a preflighted request.
However, at the end the auth headers are not sent, and the input I get is this one:
This is my front end code (JS):
fetch(generalInfo.url.api+"users/"+userId, {
method: 'GET',
headers: {
"Content-type": "application/x-www-form-urlencoded; charset=UTF-8",
"Authorization": "Bearer "+accessToken
},
withCredentials: true
});
While this is a middleware in the API backend:
//Allow the cors from every domain
module.exports = function (req, res, next){
res.setHeader('Access-Control-Allow-Origin', req.host);
res.setHeader('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE,OPTIONS');
res.setHeader('Access-Control-Allow-Headers', 'Authorization');
if(req.method === 'OPTIONS'){
return res.send(200);
}
next();
}
Can anybody help me?
According to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
In particular, a request is preflighted if any of the following conditions is true:
If, apart from the headers set automatically by the user agent (for example, Connection, User-Agent, or any of the other header with a name defined in the Fetch spec as a “forbidden header name”),
The forbidden headers include:
https://fetch.spec.whatwg.org/#forbidden-header-name
Which has Access-Control-Request-Headers which we can see is being sent with your request. This explains the use of a preflight.
I think the process looks ok - but in your response headers to the preflight i notice the access control allow origin is api.myapp.com whereas in the request if was on port 8888. I think in the response you should have the port number if it's not 80 for http. See https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy. An origin is the same if:
Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages. You'll see this referred to as the "scheme/host/port tuple" at times (where a "tuple" is a set of three components that together comprise a whole).
So i think the issue might be that your preflight is saying to the client that only api.myapp.com is allowed but the actual request might be made to http://api.myapp.com:8888 so the origins don't match. Or have I misunderstood what you are trying to do?
You must remove "8888" port of your api url, the api server has to have already a port setted for api.myapp.com address
This question already has an answer here:
Which HTTP status code to say username or password were incorrect?
(1 answer)
Closed 5 years ago.
I am implementing an endpoint which offer some secret data and I want to make a simple verify mechanism. Which status should I response when user does not have the correct crediential?
400? 403? Or something else?
thanks.
You should use 403, HTTP status code 403 responses are the result of the web server being configured to deny access to the requested resource by the client.
See HTTP 403
You can use 401 if you intend to authenticate via www-authenticate header field. If the authentication information was incorrect or missing send 401.
Or use 403 to notify the sender of the request that he is not allowed to access the requestet content. According to the documentation the response should state the reason why the request was refused.
If you do not with to do so you could alternatively send a 404.
For further information see the linked Documentation.
w3.org http Protocol
EDIT: improved from link only answer.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
receiving the Facebook username and password of our users via SMS we want to connect them with our Facebook app by using PHP and CURL only.
I got the CURL working to login the user and to navigates to the Facebook App Center.
But now, can anyone help me I to make the ajax url call using cURL and setting the variables to their proper values?
Many thanks in advance!
I used Firebug to get the http request header(example):
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Cookie datr=uwFOULplg04OUafUhiZ0HuH3;
fr=01N5ffPgbtXUfTSbp.AWXd1IvmHVuGxr9GDRK9hpoYg
7g.BQTgHg.-8.AWXCZ9aq; lu=Rg6On5bhniBKFnROJOb7OApg; locale=en_GB;
c_user=100002533085804; csm=2; s=Aa5wBFIhYob4hVne.BQiowf;
xs=61%3AaaoKTpJSVJO6PA%3A2%3A1351257119; act=1351265044404%2F0%3A2; p=6;
presence=EM351265035EuserFA21B02533085804A2EstateFDsb2F0Et2F_5b_5dElm2
FnullEuct2F1351256551BEtrFA2loadA2EtwF1590615573EatF1351264924097G3512
65035755CEchFDp_5f1B02533085804F1CC; sub=34605056
Host apps.facebook.com
Referer https://apps.facebook.com/thefind/?fb_source=search&fb_appcenter=1
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0.1
X-SVN-Rev 656775
and the variables with their values:
__a 1
__user 100002533085804
filter[0] app
filter[1] page
filter[2] group
filter[3] friendlist
lazy 1
token v7
viewer 100002533085804
You should not be collecting your user's password to log them in! This is a TOS violation and is a poor practice.
Instead, if you want to do this in PHP, you should be using the server side login method to authenticate your user. Once they complete this process, they will have authenticated your app.