Thanks a ton Richard !!
I will ask my colleague if this works in angularjs on Monday; my gut feel
is it will :)
Thanks a ton guys !!!
Thanks and Regards,
Ajay
On Fri, Apr 14, 2017 at 5:01 PM, Richard Stanway
wrote:
> You're correct - placing the username and password in the URI is just as
> s
You're correct - placing the username and password in the URI is just as
safe as any other method as long as it's going over HTTPS, and the
credentials should never appear in any access logs (unless you specifically
choose to log the Authorization header).
On Fri, Apr 14, 2017 at 6:47 AM, Ajay Gar
Hi Richard.
You have got me thinking ...
https://username:password@1.2.3.4/ works, even without ANY of the
"add_header" and "proxy_set_header" directives.
So, now the only thing that worries me is security.
http://stackoverflow.com/questions/4143196/is-get-data-also-encrypted-in-https
indicates
On Thu, Apr 13, 2017 at 08:20:15PM +0530, Ajay Garg wrote:
Hi there,
> There has been some progress, but still get a "CORS preflight did not
> succeed error".
What do the nginx logs say happened?
What should the nginx logs say, if everything worked the way you want
it to?
> Following is receiv
You're missing the "Authorization" header in
your Access-Control-Allow-Headers directive.
You can alternatively pass the basic auth in your URI, eg xhr.open("GET", "
https://username:password@1.2.3.4/";) rather than crafting it manually.
On Thu, Apr 13, 2017 at 4:50 PM, Ajay Garg wrote:
> Stran
Strange, but rebooting the machine caused the credentials-popup to be
seen again :-|
Sorry for the noise here.
There has been some progress, but still get a "CORS preflight did not
succeed error".
Following is what I am doing.
a)
Following is the server-block in /etc/nginx/conf.d/default.conf ::
Upgraded to 1.11
Now, things get worse, I am not being prompted for any credentials (even
with all browser cache cleared), even with the following
/etc/nginx/conf.d/default.conf
##
server {
listen 443 ssl;
s
On Wed, Apr 12, 2017 at 06:13:19PM +0530, Ajay Garg wrote:
Hi there,
> We are facing the following issue :
>
> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the
> remote resource at https://1.2.3.4/. (Reason: CORS header 'Access-Control-
> Allow-Origin' missing).
What's
Hi Richard.
Thanks for the help.
I added 'always' as the last argument in all the "add_header" and
"proxy_set_header" directives.
Unfortunately, I receive the following on the very first "add_header"
directive ::
#
2017/04/12 17:18:22 [emerg] 2
Your are using auth_basic, so the 401 response code is not in the range
that add_header works with ("Adds the specified field to a response header
provided that the response code equals 200, 201, 204, 206, 301, 302, 303,
304, or 307."). You need to use "always" if you want to include the header
in
For the record, here is the server-block ::
#
server {
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
add_header 'Acc
Hi All.
We are facing the following issue :
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the
remote resource at https://1.2.3.4/. (Reason: CORS header 'Access-Control-
Allow-Origin' missing).
Have tried everything I could find on the google, but nothing works
(whatever
12 matches
Mail list logo
