Nest Developer - How to use virtual devices without affecting real devices? - nest-api

So I signed up for a developer account, with the same email address as my home Nest account.
Now, if I add a virtual device via the Nest Developer Chrome Extension, it shows up via web, in-app etc.
Do I need to create another developer account so that I can have a sandbox which doesn't interfere with my real-world devices?

Best practice would be to create a separate development account so your virtual devices do not affect the behavior of a real household. Because accounts are free, you can use common techniques like + signs (me+test1#example.com => me#example.com for most email providers) to setup accounts for all sorts of interesting test scenarios.
Then, when you have your code functional, you can pair with your main account an become your first beta tester.

Related

Multiple API Keys for multiple websites for web designers

I am a beginner web designer and I am struggling to find relevant information online as to how I should go about managing my API keys for clients! I would really appreciate any tips or insights on how I should go about this!
I hold my own google account and already have my own API key (Javascript API) for my own website. Although, when creating websites for clients, is it okay to use the same API Key? Or should i create a new API Key for each client in my own account (creating new "projects")? Or should i be creating a google account for each client and then creating each client an API Key through their own account?
I also know that there are usage limits on API Keys so I want to ensure I dont exceed these if using one API for multiple sites. How can I monitor this?
Looking for any advice on the best and most efficient way to go about this. I do not know too much on how API Keys work!
Much appreciated :)
I will be using Google API as an example. Yes, you should always Create a new project for each client there are a multitude of reasons why you should do this and you already mentioned some of this
API query usage limit.
Separated client billing & usage breakdown for each project.
Security and revocation of compromised APIs.
Restricted security profiles, domain whitelisting, IP address, device usage etc..
Access management and role management.
Traffic and analytical reasons.
Creating credentials
Depending on your organisation needs and project scale, for us, we Create credentials (API key/ OAuth ID/ Service Account Key) for every platform the key will be used. For example, if we are developing an e-commerce website that comes with an app, we would issue 3 keys. (1 for web, 1 for Android apk, 1 for iOS app). This allows us to fine tune the access permissions and let us track usage.
What works for you?
If you are a freelancer or work in a small enterprise, the least you should do is separate every client by projects. There is no need to create a new Google account for each project. (You can always transfer ownership of projects to another account if your client requests at a later time)
The above screenshot is how we categorize items in our account, for each project we are contracted for (could be the same client) we will create a separate project entry.

Adding developers to Nest account

Can I add other developers to my Nest account? I would like each member of my team to have their own Nest user account but share the same client and test devices.
Unfortunately not at this time.
The best practice with the current setup would be to create a group Nest Account for development (using a group email address, most IT departments have self-service for this) and a separate account for production (which you should do anyways)
If you would like to suggest better account management features, the best place to do so is on the Product Suggestions board in the Nest Community.

Strategy for Windows Azure Accounts Management

From web search it appears that to be able to manage Windows Azure services, you need an account with one of the admin roles (service administrator, co-administrator etc).
From project management point-of-view, what is a good strategy to manage accounts for your company if you have several developers working on Azure?
Examples
A simple strategy could be to have a few designated administrators (e.g. team leaders) who upload the code while other developers use Azure Emulator on their machines.
Another example would be to have a shared Azure account used by many developers (not sure about licence implications for this one!).
These are just off the top of my head and have their drawbacks. What strategies do you use?
2 Places I've worked we've done the following.
Single Common A/C
Create a common email-distribution group (myteamonazure#mycompany.com)
Register this mail address as an MSN Passport
Use it to sign up with Azure.
Pro's: Everyone on the team gets mails regarding the account.
Con's: If someone leaves the team, we need to change the account password.
Individual accounts
Let each person signup with their own account. (Mandate it must be their company email... not personal msdn passport)
Make one person the super-admin, and the rest co-admins
Pro's: If someone leaves, it's far easier to just revoke their credentials/privs
Con's: Lots more accounts to keep track of depending on the size of your team, particularly if you're company has a single Azure Account, with lots of different apps/projects hosted on it.
Personally, I prefer the second option as it's more secure/easier to revoke access to individuals.

Google Multiple Sign-ins - Is there a way to specify the account in the URL?

We recently switched our team to Google Apps and with that, everyone got a Google Apps account . However, for those of us with a GMail account as well, this makes it so that bringing up Gmail in your browser opens up either your personal account or your Google apps account.
Even though GMail has multiple Sign-ins enabled for both of my accounts, I still have to spend time switching through both accounts.
I was wondering if there was a way to specify the account I wanted to use in the URL directly, which would allow me to create a bookmark for GMail for both of these accounts:
something like:
http://mail.google.com?a=firstaccount#gmail.com
http://mail.google.com?a=workaccount#googleappsdomain.com
I just don't believe anyone at Google has never thought of this! :-)
The same question applies to all of Google's services too I guess (docs, sites, etc...)
https://mail.google.com/a/googleappsdomain.com/
This works like a charm, with one exception: regular gmail.com accounts. https://mail.google.com/mail/ will direct you to the inbox for whichever account you logged in as first. My work around has been to make sure I log into my personal e-mail first (but this at least avoids having to log into the rest in a specific order).
For an access to multiple gmail adresse you can use this :
https://accounts.google.com/ServiceLoginAuth?continue=http://mail.google.com/gmail&service=mail&Email=yourname#gmail.com

What are the best practices for internal security standards in companies with large SAP investments?

I work in a large company, and I'm interested in best practices for internal security standards. We have a large ($500 million +) investment in SAP, and we also have .Net and a bit of Java EE in our internal environment.
I've found some documentation from MS and SAP, but it's outdated and not very specific.
So far, it looks like we could end up using Active Directory as the standard user store for all non-SAP applications, and SAP CUA / Portal for SAP applications.
Some concerns I have about AD are:
Being able to aggressively time-out for applications on shared computers (A small number of our applications run in remote offices in rural areas with a limited number of shared machines. In these cases, a supervisor with "power user" privilages could use an application, and then a clerk who should have only basic privaleges could use the same machine immediately after)
Being able to force the user to enter a username and password instead of just having the credentials read from the user's workstation - Because it's pulling the same credentials for the desktop and email, it won't currently ask users to log in. This is a concern for applications on shared computers as well. (See the explanation in the previous bullet)
As far as synchronization between AD and CUA is concerned, I want to approach this very carefully. We have a limited budget, and I want to make sure that if we end up putting something in place to synchronize the stores, that it's rock sold and provides excellent value. If we can't find something like this, I'd be comfortable coming back with a recommendation that the stores remain independent. SSO would be ideal, but I've worked with trying to get an SSO application up before SAML, and it wasn't pretty.
Acronyms:
SSO: Single Sign-On SAML: Security
Assertion Markup Language
CUA: Central User Administration (For SAP)
There is a lot of possibilities on this subject.
We had a customer that updated both their AD and their SAP user list from SAP HR. The idea was that the OM module contained all employees. You could export daily a list of all active employees to the LDAP, with basic informations (firstname, lastname, employeeId, login...). For the SAP system, unit/function/job needing a sap access where tagged and user where created/removed daily.
In fact, all employees had a SAP account, but only those tagged had a "dialog" one. Those account are allowed to connect via SAPGUI, others had to use the portal, which is a less costly licence. A set of rules allowed to set the roles for the managed users. The goal was to minimize user management and limit the inexorable grows of autorisation that comme from moving from job to job an organisation. (this was for 105000 employe, with a lot of personnel movement).
Thus SAP was not directly linked to the AD, but they where synchronised. Depending on the system (Development, qulity, integration, production), SAP was configured with time-out. You could also have différent password for separate systems.
Of course the reverse is also possible : interrogate a LDAP from SAP to manage SAP's accounts, without beeing directly linked to the LDAP. transaction LDAP can problably give you some informations.
hope this helps
Edit : the synchronisation was done by an ABAP program. that program was run every day at four, and created/deleted/modifed some accounts in the LDAP. After that, another program added some technical informations to the LDAP entries, informations that where not available to the SAP RH system (such as the mail server to use for a given employee, depending on its location around the world). The entries where then checked for consistency, and send to the master LDAP.
This program only managed personnel and units. Groups (authorization for others application) where managed either manually, or by others programs. Thus non SAP data were also stored in the LDAP.
Regards
Why is it a problem if users don't have to log in? Wouldn't that be more convenient for users? And wouldn't it give them further incentive to log out of the application?
The project I'm working on now uses AD, and we have a mapping table inside of SAP to map AD accounts and SAP accounts. Syncronisation is manual, which may or may not work for you, but there's no real technical risk.
I wish I could give you more information, but I haven't been very involved with that side of things. I can look into it,though.
You might want to look at OpenSSO - it has agents for SAP and it will integrate with AD as the user store. It's also pretty solid - Verizon use it for 40 million customers to log in to their web site.
IMHO.
This is not good solution to use different users in one windows session. Especially users authenticated in AD.
Usually it will be going that USER1 running sap client without closing , and work another USER2.
You get non-personified users. And don't forget users don't like perform all instructions.
We used thin client like citrix and SSO. It is full split data and authorization between users. And you have to use different sessions for users on workstation. The good think is no critical data store on workstation.
Not good idea and not secure but you can use run as different users
application in Windows environment in same session. But it is not secure solution for big company.

Resources