In the HERE platform, I added an App under Apps in the Access Manager. I then generated an API key for this app. This API key works when using it on our webapp.
However, when I add a "Trusted domain" and "Enable trusted domains", the key no longer works. I added all variations of our domain:
sub.domain.com
https://sub.domain.com
domain.com
I have waited multiple hours between different attempts and it still doesn't work. When I disable trusted domains, it works again...
The following question seems related but there is no solution: HERE Maps specific domain feature not working
Is this feature not working properly, or am I doing something wrong?
you would need to pass the "Referer" + Your trusted domains in the header.
Example: If you have your IPV4 address in the trusted domain and use some tools like postman to test it. Then add Referer and the IP in the headers. It should work. Thanks
Related
I'm developing a website using ASP.NET identity that will work with subdomains that identify a client using some information from here I've got subdomains working locally, but I can't get it to work with OAuth.
For example, if I got to https://localhost:44301 and try to login with Google, everything is fine. In my Google console I have https://localhost:44301 under "Authorized JavaScript origins" and https://localhost:44301/signin-google under "Authorized redirect URIs". But when I go to https://foo.localhost:44301 Google will respond with:
Error: invalid_request
Invalid parameter value for redirect_uri: Non-public domains not allowed: https://foo.localhost:44301/signin-google
When you try to log in. I can add https://foo.localhost:44301 to "Authorized JavaScript origins" in the Google console, but it won't let me add https://foo.localhost:44301/signin-google under authorized redirect URIs because it will complain:
Invalid Redirect: https://foo.localhost:44301/signin-google must end with a public top-level domain (such as .com or .org)
Some other questions and answers suggest redirecting all subdomains to a single domain for OAuth, but ideally I want to keep logins per subdomain. So if you use google to sign it to foo.mydomain.com it will be separate from bar.mydomain.com and I don't think that'll work if I have to redirect both to the same single domain (although I'm not sure that's going to work without separate projects in Google.
Google and in general other OAuth2/OIDC providers will support redirecting to sub-domains. Your specific problem is that you seem to be trying to use sub-domains of localhost which is in the list of Special-Use Domain Names (RFC6761) and it seems Google has additional constraints for those ones.
However, this is not a real limitation because on production you'll use a public top-level domain from from where you'll have the specific sub-domains.
If you need to have this working for local development, you can use localtest.me which allows you to set a sub-domain you like (foo.localtest.me and bar.localtest.me) while still ensuring that the domain resolves to your local machine (127.0.0.1). This should stop Google from complaining about it...
How to prevent someone just taking my API keys from the client side javascript code and starting to use my HERE subscription for some other use.
I noticed HERE provide an option to secure the API keys for a certain domain on the applications management page: "Secure app credentials against a specific domain". I have set up this option and also put domain there but I do not see any change on my app behavior.
The application still continue working fine on my PC. Shouldn't the HERE API stop working as web server is running on localhost and not on the defined domain.
My app is running fully on browser, and only static files come from the server (http://localhost:8083/index.html). I am using the HERE javascript API.
I tested also running the app on external cloud service on different domain than localhost. Results are the same. My conclusion is that the setting "Secure app credentials against a specific domain" just has no impact and does not work. Checked also the api response headers and all origins are accepted.
Access-Control-Allow-Origin: *
In your HERE dashboard, you can set the application id and application code to only work on a particular domain or set of domains. If the tokens are fixed to a domain, it won't matter if someone takes your tokens because only the listed domains can use them. If you don't secure the tokens to a domain, then someone will be able to use your tokens if they find them.
I am able to complete the connect to custom domain step successfully and https://example.com is correctly loading my static file app which is hosted on Firebase.
However, browser is warning about the site's SSL certificate is not matching example.com. I looked at the certificate and it is of firebase.com, not example.com.
This certificate is provided by Firebase for example.com (my custom domain name) and I expect it to be matching it. Is this expected?
I know the other solution is to get my own certificate for example.com. However, it seems that Firebase won't let me deploy my own cert.
Update
I retried it some time back and it is fixed. And the whole suite of Firebase db/functions and corresponding sdk/cli are working really well. Great for small dev team.
Solution: Don't have to do anything about it other than just wait.
Faced the same problem when connecting to my custom domain on Firebase Hosting. However, it will only be insecure when the status is pending. The status can be found on your Firebase Hosting Dashboard.
My connection turned secured with a green lock after around 3 hours, and the status reflected in the dashboard changed to connected.
This error message called domain name mismatch warning that occurs because of the domain is pointed to a shared IP addresses.
You need to confirm that your hosting provider supports SNI technology which allows install different certificates on the same IP. Please ensure that the certificate is installed correctly on your desired server and enable SNI. If your hosting provider doesn’t support SNI technology, you should have to dedicated IP to host your SSL.
In the add custom domain menu, check by changing the setup mode to advanced and complete the provide token on existing domain task by copying the TXT value to your dns records according to the instruction.
This solved my problem.
Google Analytics recently started showing PHP scripts as referrers to my website, for example:
localhost/index.php
EDIT: This is a recent surge in activity coming from India. It is not coming from our own services, such as our web host, or a backup service. It is also coinciding with spam users on my websites from India, so I know this is intentionally malicious behavior.
Any suggestions on how to investigate further and prevent it? We are running on Django, hosted on AWS, if that helps.
If the server have subnet or the server is on your system it may cause that kind of referrers if request from the subnet.
Well, In case of Django if somebody from your team is running a development version of your application with the Google Analytics tracking code, then things like this can show up. Not only will localhost show up in your Referrers, but your aggregate metrics like Bounce Rate, Time On Site, Conversion, and others will be incorrect because the unusual behavior of a developer's will be mixed in with that of normal users and skew our results. There are basically 3 steps to fix it :
Add a Google Analytics exclusion filter
1) Open Google Analytics and choose your property view.
2) Navigate to Admin.
3) Click on Filters under the View column.
4) Click on New Filter.
5) Create a new "Predefined filter" which excludes traffic to the "localhost" hostname.
Edit: Configure ALLOWED_HOSTS in Django settings
This is a security measure to prevent an attacker from poisoning caches and password reset emails with links to malicious hosts by submitting requests with a fake HTTP Host header, which is possible even under many seemingly-safe web server configurations. Django 1.5 introduced the allowed hosts setting that is required for security reasons. A settings file created with Django 1.5 has this new section which you need to add:
ALLOWED_HOSTS = [
'.example.com', # Allow domain and subdomains
'.example.com.', # Also allow FQDN and subdomains
]
Add your host here like ['www.antodominic.com'] or ['*'] for a quick test, but don't use ['*'] for production.
Hope this helps ...!!
Cheers.. :)
If you have a website that is externally accessible, then yes- someone is trying to hack your website... and every other website in existence. It's a fact of life.
Your localhost referrer is not necessarily indicative of malicious behavior, however. It's more likely that your dev instance, or someone else's dev instance of their site with links to your site, is creating the entries in your analytics.
However, if it's a referer with a link to another site in the querystring, then what you're falling victim to is referer spam attempts. If you want to prevent them, you can block them via htaccess if you're running on Apache, or via web.config if you're running on IIS. Just replace the pertinent bits regular expressions, or better yet, add to them.
When I try to get data in a mobile flex app from a secure site, I get following alert:
A secure connection with this site cannot be verified. Would you still
like to proceed? The certificate you are viewing does not match the
name of the site you are trying to view.
For each call, I get the popup. If I keep on clicking Yes, the app works fine (but I would like to avoid that ;-)).
Any ideas? Apparently, the url from where the request comes, is not the same as defined in the certificate... But what is the url if called from a mobile app (standalone)? It's neither an error, because you can click on yes. So it's more that the client gives a warning. The annoying thing is that you can't accept it permanently...
This is the same whenever a cert is not correct and chrome or firefox alerts you and asks if you want to proceed. You cant accept a faulty cert on the behalf of your users. The easiest way to fix this is to tell the site owner to get a proper cert.
Check with your system administrators of website whether certificate installed is issued for your domain. It appears that certificate is issued for a domain https:///xxxx where as it is installed on https://yyyy
Bypassing is OK for testing , it seems finally you will have to get this corrected
In my experience this only comes up with self-signed certs, expired certs, and when you are calling the cert by a URL that is not identified in the cert.
With most certs they are associated with a single host/domain combination, i.e. https://www.domain.com
That means that they cannot be used with any other domain host combination. Not even http://domain.com or https://sub.domain.com.
There are certs that will support different hosts on the same domain (www.domain.com, sub.domain.com, etc). They are called wildcard cert. They are very expensive compared to normal single domain certs.
My guess is that in the browser you are calling www.domain.com but in your AIR app you are calling domain.com or calling some other host. That or you have permanently accepted the improper cert in the browser.
I have never have a problem with anything improperly identifying a valid cert. Not a browser, Flex app, AIR application. Ever.
If you view the cert in the browser you should be able to see what domain/host it is registered to. Make sure you are using exactly that. Any variation will cause the error.
As a temporarily solution I added some exceptions to the URL Rewrite Module, so that communication by Mobile App can be done with HTTP. But it's no longer secure, so I would rather use HTTPS.
I have also faces this issue and simple solution is fixed the certificate issue. If not possible then forget about using the HTTPS use HTTP only. So you never get any complain about any certificate issue.