I'm just starting with Google Maps API (GMA for short) and I came to understand it is good to have the GMA Key (GMAK for short) regardless of not being necessary IF you are not to set foot beyond the limit quota. It happens that I probably won't but that is not the concern here.
I just need to note that I'm referring to the v3 version of GMAK. And I have not previously used a GMAK or the GMA; I have always used the code you get from Google Maps itself. So I really don't know much regardless of searching a good amount of time and knowing I will use JavaScript to use the GMA.
I have a lot of websites that I own and some more I administer. But just recently I got the need for GMA for myself and some clients will need too. So here is the question:
Do I need to use a GMAK for each website - meaning creating a Google Account for each website? I mean, is the quota specific to the GMAK or each service will have it's own quota?
And supposing the GMAK quota is specific to website/app and not the GMAK itself: in case of me not being the administrator for one of my ex-clients website anymore, should I inform that I will revoke the GMAK access for that website? Or should I make them provide one GMAK to begin with and not worry it if they finish the contract with me?
I worry and fear that Google will revoke my GMAK because maybe OR all the websites together will reach the quota OR some website of my client will reach it and if they don't pay me, all of my other services will lose the function by not having a GMAK.
The quota belongs to "projects", so you may say it's specific to a key, because each project does have it's own key.
When you can't give a guarantee that access to your key will be granted in the future you should either not use a key or force the client to create an own project and use the key of the client.
However, no matter if you grant access in the future or not, I wouldn't recommend to use your key at all, because when any of the clients will violate the TOS in any manner(there are more cases than hitting the quotas) your own key/project is affected(and of course any webpage/app of any client that uses the particular key). In worst case it may be that your entire google-account is affected.
So you should either use the key of the client(when available) or omit the key.
Related
I am making a website to showcase artwork. I want to add an auction functionality. I will use Angular framework and wondered if anyone had any experience doing this.
Functionality should be as follows:
Only admin users through an admin page with the specified password can add art for auction
Users can bid on auction
Auction can have a minimum price
Payment can be dealt with over email or on the website (not sure what is easiest)
Automated email response when bid has been placed
Every bid stored so if winner doesn't purchase next closes can try
Greatly appreciated,
I understand this may be a huge task - or may not be!
Yep, that's an entire project that people build entire businesses (and thus teams of developers) around.
Can it be done in a simpler fashion? Yes.
Can it be done well in a simple fashion? No.
I'll start throwing a range of things at you so that you can see how much is really involved in handling all of that. Just a glimpse.
You need hosting, there's always a fun start. Self hosting? Cloud hosting? AWS, Azure, other?
You need storage - some kind of database (though definition of such is fairly loose these days). For both user data and art/auction data.
You need to pick a back-end tech; Angular can't (or shouldn't) be the whole app. You should have something doing all of this coordinating, processing, saving, updating, deleting, etc. etc.
That's just the overview of the parts of the system as a whole, the two second version of your various points:
Admin users
Not just the ability for having users, but now you have different roles and thus different access rights and pages that are accessible depending. Though I note you use the phrase "with the specified password" which means you aren't really thinking of having an actual user-based system, just some brute-forceable basic hard-coded string put in there somewhere.
Note: especially if you're expecting to be dealing with money, this will not fly. Security is top of your list, so you need a full, proper, auth system in place.
Users can bid
Well I'd hope so, being the basis for this it seems. That's simple enough; requests through to the server to store relevant bids.
However, you need to worry about concurrency - how often will their page be updated so that they are aware of other bids? Does your page pole for changes every x seconds, or will you use websockets so that you can push updates to the clients in real time?
Min price
Yeah, sure, details details.
Payment
Over email? Outside of the odd £5 or something, people buying artworks are not likely to be happy randomly paying for things via email. Sure, maybe, depending on what you're doing and your audience, maybe that's fine. A proper website, however, will provide online payment options; that way buyers have confidence and some protection (against you, in this case).
Take payments? Two options, taking them yourself or via a third party. Doing it yourself is a pain in the backside and there's probably not much of a chance your project would pass the requisite security checks to be approved. So you'd need to work through a 3rd party - those are typically pretty easy to set up (they WANT you to use their services, after all), but it's still another chunk of work you need to do to integrate that.
Automated emails
Sure, emails, easy. Though you need to decide whom your provider is. Self hosted? SendGrid? AWS? etc.?
You'll need to keep an eye on your account every now and then as they tend to keep track of your 'reputation' and any bounces, etc. that you get, and if you drop too low, you get no service. E.g. prevent spammers.
Bids stored
Sure, everything should be stored. Bare minimum requirement.
That's just covering your points, let alone the effort of the unspoken requirements in creating an entire site that's acceptable for use and doesn't scare the users away two seconds after they look at it - it needs to look reputable.
You need registration pages, account management pages, galleries, search features (if you're that big?), admin pages (user management, auction management, etc), the lots themselves with the whole bidding mechanisms involved...
That said, you can probably put one together relatively quickly with various website builders - wordpress has a bajillion plugins and I'm sure probably runs half the websites out there at this point, and likely has everything needed to do that; but it wouldn't be Angular, and it wouldn't be your stuff; you're trusting whomever developed those things to have them work, maintain them, etc. etc. while you figure out how they all work and get it all running...
TL;DR: There's a reason devs are pretty well paid. It's always more complicated than you think.
I'm using Giphy's API and currently have a development key. I am looking to deploy my site but don't know whether it is a public facing key or a private one, and cannot find an answer online nor after asking them directly.
Here is the official response to this question from GIPHY:
GIPHY APIs are designed to be used on the client side (and hence the API key too). You should go ahead and use it that way. Once development is complete - please apply for Production access for the key through the Developer Dashboard, this removes Rate limits associated with a beta key, so you don't have to worry about high traffic.
Lastly, and most importantly - GIPHY has monitors setup for API key abuse and we'll reach out to you if anything happens. We definitely don't want you to worry about it.
From here
Seems shouldn't be worrying about it.
While I generally tend to agree with Jay's answer, after reviewing their introduction and the specific javascript sample it seems to me that this key should be used from the browser and as a result it is practically a public key.
I would assume that later on in the process, to avoid abuse with production API key, they might only serve requests coming from a domain you registered along with that key.
Development key is anyhow for limited testing purposes as far as I understand so that's less of an issue if there's no registered domain for that.
On Production environments, Javascript based analytics scripts (Google Analytics, Facebook Pixel etc.), are injected into most web applications, along with the Unique ID/Pixel ID, in plain Javascript.
For example, airbnb uses Google Analytics. I can open up my dev console and run
setInterval(function() {ga('send', 'pageview');}, 1000);
which will cause the analytics pixel to be requested every 1 second, forever. That is 3600 requests an hour from my machine alone.
Now, this can easily be done in a distributed fashion, causing millions of requests per second, completely skewing the Google Analytics data for the pageview event. I understand that the huge amounts of data collected would correct this skewing to a certain extend, but that can be easily compensated by hiking up the amount of requests.
My question is this: are there any safeguards to prevent competitors or malicious individuals from destroying the data integrity of applications in this manner? Does GA or Facebook provide such options?
Yes,but the unsafe part don't comes for the Javascript. For example, you can use the measurement protocol to flood data to one account. Here you can see a lot of people in the same comunity having thoubles with this (and it's quiet simple to solve.)
https://stackoverflow.com/search?q=spam+google+analytics
All this measurement systems uses HTTP calls to fill the data on your "database". If you are able to build the correct call you can Spam Everyone and everywhere (but don't do it, don't be evil).
https://developers.google.com/analytics/devguides/collection/protocol/v1/?hl=es-419
This page of Google Analytics explain what is the protocol measurement, Javascript only work as framework to build and send the hit.
https://developers.google.com/analytics/devguides/collection/protocol/v1/?hl=es-419
But, so not everything is lost.
For example, if you try to do that on you browser with that code, The Google Analytics FrameWork limit to 1 call per second and 150 per session (or cookie value). Yes it's not complicated to jump that barrier, but after that other barriers will come.
So if you use the Javascript framework are safe. Now imagine you do the same with python, sending http to the Google Analytics server. It's possible but:
So here are 2 important things to says.
Google Analytics has a proactive "firewall", to detect Spammers and ban them.(How and when they do this is not public), but in my case i see a lot of less spammer that few years ago.
Also there is a couple of good practices to avoid this. For example, store only domains under a white list, creating a filter to allow only traffic from your domain
https://support.google.com/analytics/answer/1033162?hl=en
Also it's a very good practice to protect you ecommerce, using a filter to include only data from certain store or with certain parameter, "for example brand == my brand" or "CustomDimension== true". Exclude transactions with products over $1.000 (check your limits and apply proactive filters). All this barrier make complex to broke.
If you do this, you will protect your domain a lot(because it's too much complicated to know the combination of UA + Domain Valid when you create a robot), but you know, all the system can be broken. In my experience i only see 2 or 3 cases of damage comming from spammer or people who wanna hurt, and in all this case could be prevented if I created a proactive filter. Usually spammer only spam ads into your account,almost never want to hurt you. Facebook, Piwik and other Tools happens more or less the same.
My problem is simple : I would like to do some statistics on a website my friends and I visit.
So I would like to find a way to connect each instance of my info-gathering google chrome extension in order to gather them in a common place for analysis.
As a first thougt, one ideal solution would be to get read-write access to a shared google drive spreadsheet, but I am open to other solutions.
Is it feasible ? Can anyone point me to the good direction ?
Thanks a lot
A spreadsheet is easy and works well for few users and rows, however the easiest way is to use google analytics, extensions support them and there are samples for custom events.
If you go the spreadsheet route use appendrow to avoid concurrency issues.
You would need to use oauth for spreadsheet access or set sharing to public write.
For a more sophisticated solution with total control of the data and scalability use Google bigquery.
Question: What precautions should I take when I let clients add custom JS scripts to their pages?
IF you want more details:
I am working on a custom CMS like project for a company, The CMS has number of "groups" that each subscriber "owns" where they do their own thing.
The new requirements is that some groups want to add google analytics to see how they are doing. So I naturally added a column in the table and made code adjustements so if there is some data in that column, I just use the following line in master page to set the script out:
ScriptManager.RegisterClientScriptBlock(Page, typeof(Page), "CustomJs", CustomJs, true);
It works just fine, only, It got me thinking...
It's really easy for someone with good knowledge of how to access cookies etc from from js. Sure, each group is moderated and only super admin can add this javascript, sure, they wouldn't be silly enough to hack their own group. Each group has their own code so its not possible to hack other groups BUT STILL
I am not really comfortable in letting user's add their own javascript codes.
I could monitor each group myself, but the groups are growing really quick and I will hit a time when I will no longer be able to do that.
So, to brief it up: What precautions should I take to avoid any mishaps ?
ps: did try to google, no convincing answers anywhere.
Instead of allowing the users to add their own Javascript files, and given that the only requirement here is for google analytics, why not just let them put their analytics ID into the CMS and if it's present, output the relevant Google Analytics code?
This way you fulfill the users requirement and also avoid the need to protect against malicious scripting.
Letting users use Javascript is in general, a very bad idea. Don't do it unless you have to.
I once I had a problem where I need to let clients use Javascript, but, the clients weren't necessarily trusted, so, I modified cofeescript so that only a small subset was compilable to javascript, and it worked pretty well. This may be waaaay too overkill for you.
You should not let your users access cookies, that's always a pain. Also, no localStorage or webSQL if you're one of the HTML5 people, and, no document.write() because that's another form of eval as JSLint tells you.
And, the problem with letting people have javascript is that even if you believe you have trusted users, someone may get a password, and you don't want that person to get access to all the other accounts in the group.
Automatically recognizing whether some JavaScript code is malicious or sandboxing it is close to impossible. If you don't want to allow hacking your site you are left with only few options:
Don't allow users to add JavaScript at all.
Only allow predefined JavaScript code, e.g. for Google Analytics.
Have all custom JavaScript inspected by a human before it is allowed to display on the site. Never trust scripts loaded from third party sites - these can change from one day to another and turn malicious.
If you have no other choice, you may consider separating path/domain of user javascripts (and cookies).
For example your user have page:
user1.server.com
and you keep user pages at
user1.server.com
So, if you set session cookies to the user1.server.com, it'll render them unobtainable for user scripts from other domains (e.g. user2.server.com).
Another option may be executing all user's javascript at server JS engine (thus controlling all it's I/O and limiting access to browser resources).
There is no simple and easy solution anyway, so better consider using options from other answers (e.g. predifined script API, human inspection).