I've spent the day searching for a way to restrict the google cloud storage json API to only accept calls from our server ip (note, I am using the java client).
I found a really old post that seemed to indicate that it was possible. https://groups.google.com/forum/m/#!searchin/gs-discussion/Whitelist$20/gs-discussion/nTwMuygttbA
But things seem to have changed since then.
I tried looking in the quota section in the console but can't find anything there either.
Is this possible? Where can it be configured?
Related
I have a client and whoever designed their site put it in Compute Engine. I am totally lost, no clue about this. I do see a bucket but there is only a footer.php in it. The site is a multi wordpress and I can not find where the files are stored or how to access phpmyadmin to see the database.
I ask this because the site is having many issues, starting with ssl expired, php is out of date and now I can not login or see the site because it is giving a 500 error or white page of death.
Tried to find what caused the error but nothing.
Site is http://nextstudy.org
Can anyone help or direct me on what I can do to get to the files and maybe get it off of compute engine?
Appreciate you reading this............
Diana
GCE does not host files from a bucket, but it runs VM instances off disk images.
Unless being assigned an admin role in Cloud IAM, there's probably not much to do. And even with an admin role granted, it's still rather risky when having no clue, I mean, while it's only a single instance, Cloud Shell might help, but when it's an instance group, the deployment may work whole different (up until the point where the servers are spun up from nothing but a shell script, which subsequently makes editing individual instances quite meaningless).
I am unable to access Google Cloud DNS page.
All it shows is:
"DNS API is being enabled. This may take a minute or more."
Then it reloads and repeats showing the same message.
The API is already enabled, and the records I created works. No problem with DNS.
I need to modify records, but I can't because of this problem.
I tried opening the page in different computers and different browsers without addons, same result.
If there is a better place to ask, please do tell.
Thank you.
You should be able to access the page regardless of what computer / browser you're using.
If you cannot it's either a temporary outage which you can check here or a bug.
The only thing to do here is to contact paid support for more immediate help and if the time is something you can afford report this at Google's IssueTracker and get help for free - however it may take a few days. It is possible that only you are affected. Please describe the issue in as much detail as possible - this will expidete the process.
We keep static files (images, javascript, and css) for our websites stored in a Google Storage bucket with different folders for different types of resources. Each file is accessed via its name coupled with a custom subdomain mapped via a CNAME record to the appropriate Google Storage bucket.
This approached has worked fine. Today, however, when attempting to access our main website in Chrome's incognito (private browsing) mode, all pages on the site wouldn't load. After some detective work, we've determined that the problem is with the files stored at Google Storage, which are not loading.
Unfortunately, this doesn't seem to be a problem specific to Google Chrome. It occurs in the private browsing modes in Firefox and Internet Explorer as well (at least on the Windows 8.1 Professional platform we're using for testing).
The problem appears to occur only if we use the CNAME-based approach for accessing a file. For example, if this method is used in a private browser window to access one of our image files on Google Storage,
Image of a crowd on Google Storage - direct access to Google Storage
the file can be viewed without a problem. If, on the other hand, the file is viewed in a private browsing window using the CNAME approach, like this
Image of a crowd on Google Storage - access via CNAME
the image will not load.
What's worse, for reasons we don't completely understand, once this problem occurs in a private browsing window, it will continue to interfere with the proper viewing of the website in regular (non-private browsing) browser windows in the case of some browsers.
Has anyone encountered this problem and, if so, found a solution for it?
Thanks in advance for any tips or suggestions.
UPDATE (2015-05-26)
This problem is still under investigation. It may be ISP-specific, although our ISP (Verizon) believes it is a problem on Google's end. An attempt to resolve the problem yesterday by tweaking some DNS settings seemed to solve the problem, but that was only temporary. We began to experience the problem again today. I will update this posting further as more information becomes available.
ADDITIONAL UPDATE (2016-08-25)
(Note: I originally wrote this update on 2015-05-26, but failed to post it, and discovered it today. I'm adding it to complete the description of the issue.)
This issue has been resolved. I cannot say for certain what the source of the problem was, but I can give further information on what exactly the nature of the problem was and what may have solved it.
As I mentioned in the comments below, this appears to have been an issue that was relatively isolated. Further investigation revealed that the problem was occurring only with access to the particular subdomain through Verizon Internet service (land-based or mobile) in the U.S. I do not know if the problem was a regional problem within the Verizon system, or throughout the entire Verizon system. But I do know it affected both landline and mobile access using Verizon.
The problem also evolved. What started as a problem accessing files at the subdomain in a browser's incognito mode became a problem regardless of what browsing mode was used. That said, it was only a problem if the attempt to load files from the subdomain was used with a browser. The files could be retrieved with no problem with, for example, wget. Also, pinging the subdomain also worked fine over the Verizon network.
As the problem became more acute, I decided to do a thorough check of the DNS settings related to the subdomain. Here is where I discovered what may have been causing the problem. There was a slight discrepancy between the DNS settings at the domain registrar and the (separate) DNS service that we use.
The discrepancy didn't lead to conflicting reports as to how the subdomain should be resolved (which is probably why this problem hadn't occurred in the past). But, if I recall correctly, it led to the DNS service providing the CNAME record for the subdomain, without the registrar's DNS information fully confirming that the DNS service had the right to provide that information.
This discrepancy was corrected. Within an hour or two, the problem resolved itself -- anyone viewing the file using the two links above should be successful with both links.
I cannot say for certain, however, whether the change to the DNS settings we made to resolve the discrepancy, or some updating at Verizon, was responsible for the problem being resolved. I will say, however, that I never reported the issue to Verizon. (I didn't get that far.)
Although the DNS discrepancy had existed for more than a year or two, and had not created any problems that we were aware of, I personally think it is what caused the problem.
I'm writing a piece of software that will run on computers as well as phones.
The service uses an HTTP API for communication and will be published over the local network using Zeroconf.
Initially I published my service using _http._tcp. as the service type but I quickly discovered that both my NAS and my music receiver(!) also broadcasts themselves with that exact service type.
So the question now arises how to differentiate between my service and other services that are using HTTP.
Alternatives
Using a different service type
The is certainly the most certainly the easiest way and (almost) guarantees no other services will be picked up.
However, according to Apple1 new services should be registered with IANA. This is obviously not required but seeing as they recommend it it feels like it would be the wrong way to do it
Using the TXT record
Apple2 describes the TXT record like this:
When a service is registered, three related DNS records are created: a service (SRV) record, a pointer (PTR) record, and a text (TXT) record. The TXT record contains additional data needed to resolve or use the service, although it is also often empty.
The certainly feels like it could be the right way to do it, but I'm still not sure and it's hard to find a description of what the field should contain.
My first though would be to put something like <service_name>-<version> which will then be parsed to see which service it actually is.
My NAS seems to use this for identifying model and version numbers.
Try talking to the service
After finding a service one could always perform a HEAD request on a known endpoint and look for a known header set by the service.
This feels like a fairly slow approach and who knows what making a HEAD request to my receiver will do.
And just to be clear, this question has nothing to do with a specific language or framework, it's about the concepts of zeroconf.
I could show some code but I don't see how that would help.
First, does the service you're advertising actually meet the qualifications for _http as defined by RFC 2782. Specifically- is it not just using HTTP for a transport but is also:
can be displayed by "typical" web browser client software, and
is intended primarily to be viewed by a human user.
If no, register your own service type (there are a couple other services that use HTTP as a transport but don't meet those qualifications so they have -http as a suffix to the service name, see pgpkey-http, senteo-http, xul-http).
If yes, there are a couple ways to go depending on how strict one's interpretation of the RFC is. The least strict being just adding a TXT record as you've already noted in your question. iTunes registers itself with a TXT record in the format iTSh Version=196618.
If you're feeling a little more strict, the RFC only explicitly states that the u=, p= and path= TXT records exist for HTTP. Perhaps someone can chime in on this, but I haven't seen much discussion on whether adding TXT records to already existing entries is frowned upon or not. So with that, the other way is to just an algorithmic instance name. For example, adding the suffix "-NicklasAService" to the device name. Hopefully giving it a unique name to the local network but still making it so that the service can be easily picked out by the PTR record by just looking for the suffix.
I'm creating a iOS app that requires the user to log in at startup, and then uses those credentials to query 4-5 different services on a server over the course of the session.
The server (xyz) it self doesn't accept the credentials, but if the services that it provides are queried then they get accepted. For example https://xyz/service1 works, https://xyz doesn't.
Now what I'm wondering about is if there is anything that stands in the way of creating 4-5 NSURLProtectionSpace's at log in, one for each service on the server, and then use the corresponding protection space when use each service?
Or is there a better way of implementing something that could work in this situation?
All help would be appreciated.
Turns out that there is nothing that stands in the way of creating multiple NSURLProtectionSpace's since each is created for a separate url.