I am trying to create a skill that will reach out to an application that uses Basic authentication to render APIs (albeit i know this is bad practice). I was wanting to go down a route similar to account linking, however seems they enforce the usage of OAuth 2.0.
Is there an alternative to this or am I forced to use OAuth 2.0 in order to request APIs to a 3rd party application?
My wanted workflow:
customer enables skill
Skill card request for username/pw combo
after setup, the skill can be utilized fully
Not sure if its helpful, but Im using Lambda to run my skill source code.
That is a terrible practice.
First of all, what if your user's password includes case sensitive letters and numbers and possibly other characters?
You can use Literal Slots but they are not case sensitive and probably won't return a number-word combination either. For example your user's pass is Word123 literal slots may return word one two three
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interaction-model-reference#literal-slot-type-reference
I am not sure if you can force user to spell his password's characters and so then you can try to detect the password though... Again this sounds like a terrible practice.
So as you mentioned: Users link their accounts using the Amazon Alexa app. Note that users must use the app. There is no support for establishing the link solely by voice
I guess you have to do the linking the way amazon requires
https://developer.amazon.com/blogs/post/Tx3CX1ETRZZ2NPC/alexa-account-linking-5-steps-to-seamlessly-link-your-alexa-skill-with-login-with-amazon
Related
As the title states, I've gotten this email for both projects I've made public on Github. One is a landing page for a local business and the other is a CRUD app I have on the App Store; both of which are using Firebase as the backend.
Is the API key being visible on Github such a security risk?
I've done some research after following the instructions in the email to restrict my API and have heard that you cannot make web service requests with a restricted API key.
I just want to show my repos for the projects for the application process and obviously don't want anything bad to happen with them by doing so.
Aren't Firebase APIs meant to be public?
If so, is it just my database rules that need to be stronger/more verbose?
If any more context is needed, please let me know!
Cheers!
NOTE: I'm still very new to programming so a lot of this is over my head
For Firebase apiKey in a web app you are intended to make this key public, so you should ignore this email -- see: https://stackoverflow.com/a/37484053/771768
Hopefully Best practices for securely using API keys helps.
I'm uncertain as to what you're doing specifically that's resulting in the email but it is warranted.
Please be very careful with API keys.
As the name suggests, these are like keys in that they unlock access to stuff. With digital keys, the additional challenge is that, once obtained, infinite copies of the key may be distributed (and these are usable until the API key is revoked).
There are (often) other (complementary|alternative) ways to authenticate APIs but, as I think you've discovered, sometimes you are required to use API keys.
In the case where they're required, you should endeavor to use complementary authentication mechanisms too in order to try to mitigate overuse and you should continue to be very judicious in your publication of these keys.
I suspect you should not be including (any) keys (ever) in your GitHub repos.
One rule of thumb is that vendors (like Google) use API keys as a way to limit access to (often paid) resources. If the vendor is giving you a key, they're often (not always) using the key as a way to determine how to charge you for an API too. If you're giving the key to others, you're giving other people the possibility of potentially incurring charges on your behalf.
I don't wish to scare you but I would like you to leave this question being very cautious when using keys even if only this causes you to read up more on the consequences of using them.
I am writing an application that should interact with DocuSign to create envelopes and then download the signed document when all the signatories have signed.
There are several other use cases, but that does not matter for this question.
I am wondering what is the best way to write automated integration tests.
Do I need to automate the interaction of the signatories withe DocuSign? This would mean that I have to receive the email, click the link, etc...
Even if it seems possible, it does not seem ideal. Is there a way to "simulate" in a dev environment the actions of the signatories?
There has been a lot of talks if a document can be signed without viewing it. And the conclusion was that NO, user cannot sign a document without viewing it. User has to view/see what is to be signed. So, that part needs to be automated using Selenium or one of its "flavors" or pretty much any UI automation you are comfortable with. And Yes, that involves receiving email, clicking the link, opening a document and signing it. You can use a Mailinator or any other email service which API you can leverage to facilitate things for you.
As for other parts of DocuSign integration automation it is encouraged to use API (makes things more stable).
So, very simple workflow steps would look like this:
Use API to prepare environment, sent variables and values (in your product and in DocuSign)
Send envelope for signing using DocuSign API
Get the link to the document
Sign using UI automation
Do verification (of envelope status and more) using DocuSign API
Background: This is my first standalone web development project, and my only experience in Meteor is building the Discover Meteor app over the last summer. I come from about a year of CS experience as a side interest in school, and I am most comfortable with C and C++. I have experience in python and java.
Project so far: I'm creating a calendar management system (for fun). Using accounts-google, I have created user accounts that are authenticated through google. I have requested the necessary permissions that I need for my app, including 'identity' and 'calendar read/write access'. I've spent the last week or so trying to get over this next hurdle, which is actually getting data from google.
Goal: I'd like to be able to make an API call to Calendar.list using a GET request. I've already called meteor add http to add the GET request functionality, my issue comes with the actual implementation.
Problem: I have registered my app on the developer console and set up Accounts using the client ID and secret, but I have not been able to find/generate my 'API key' for use in the request. Here is the google guide for creating the access token by using my (already) downloaded private key. I'm having a hard time wrapping my head around an implementation on the server side using JS because I don't have a lot of experience with what is mentioned in the HTTP/REST portion of the implementation examples. I would appreciate some help on how to implement a handshake and receive an access token for use in my app. If there is a call I can make or some package that will handle the token generation for me, that would be even better than implementation help. I believe an answer to this would also benefit this other question
The SO answer that I've been referring to so far: https://stackoverflow.com/a/14543159/4259653 Some of it is in spanish but it's pretty understandable code. He has an API key for his request, which I asked this question to help me with. The accounts-google documentation isn't really enough to explain this all to me.
Also an unrelated small question: What is the easiest way to deal with 'time' parameters in requests. I'm assuming JS has some sort of built-in functionality that I'm just not aware of yet.
Thanks for your research. I have also asked a very similar question, and right now I am looking into the package you recommend. I have considered this meteor-google-api package, but it looks abandoned.
Regarding your question about time manipulation, I recommend MomentJS. There are many packages out there; I am using meteor add mrt:moment
EDIT: MomentJS now has an official package for Meteor, so use meteor add momentjs:moment instead of the mrt command above
Below is a snippet of what moment can do. More documentation here.
var startTimeUTC = moment.utc(event.startTime, "YYYY-MM-DD HH:mm:ss").format();
//Changes above formatting to "2014-09-08T08:02:17-05:00" (ISO 8601)
//which is acceptable time format for Google API
So I started trying to implement all of this myself on the server side, but was wary of a lot of the hard-coding I was doing and assumptions I was making to fill gaps. My security prof. used to say "never implement encryption yourself", so I decided to take another gander for a helpful package. Revising search criteria to "JWT", I found jagi's meteor-google-oauth-jwt on Atmosphere. The readme is comprehensive and provides everything I need. Following the process used in The Google OAuth Guide, an authorization request can be made and a key generated for making an API call.
Link to Atmosphere: https://atmospherejs.com/jagi/google-oauth-jwt
Link to Repo: https://github.com/jagi/meteor-google-oauth-jwt/
I will update this answer with any additional roadblocks I hit in the Google API process and how I solved them:
Recently, I've been running into problems with the API request result. I get an empty calendarlist back from the API call. I suspect this is becuase I make an API call to my developer account rather than to the subject user. I will investigate the problem and either create a new question or update this solution with the fix I find.
Fix: Wasn't including the 'sub' qualifier to the JWT token. Fixed by modifying JWT package token generation code to include delegationEmail: user.services.google.email after scope. I don't know why he used such a long designation for the option instead of sub: as it is in the google API, but I appreciate his package nontheless.
I'm quickly becoming proficient in this, so if people have meteor-related google auth questions, let me know.
DO NOT USE SERVICE ACCOUNTS AS POSTED ABOVE!
The correct approach is to use standard web access + requesting offline access. The documentation on the api page specifically states this:
Typically, an application uses a service account when the application uses Google APIs to work with its own data rather than a user's data.
The only exception to this is when you are using google apps domain accounts and want to delegate access to your service account for the entire domain:
Authorizing a service account to access data on behalf of users in a domain is sometimes referred to as "delegating domain-wide authority"
This makes logical sense as a user must be allowed to "authorise" your application.
Back to the posters original question the flow is simple:
1) Meteor accounts google package already does most of the work for you to get tokens. You can include the scope for offline access required.
2) if you are building your own flow, you will go through the stock standard process and calls as explained on auth
This will require you to:
1) HTTP call to make the original request or you can piggyback off some of the internal meteor calls : Package.oauth.OAuth.showPopup() -- go look at the source there are more nifty functions around there.
2) Then you need to create an Iron router server side route to accept the oauth response which will contain a code parameter that you will use to exchange for tokens.
3) Next use this code to make a final call to exchange the "code" for the token + refresh_token
4) Store these where ever you want - my requirement was to store them not at the user level but multiple per user
5) Use a package like GoogleAPI this wraps up Google API calls and refreshes when required - it only works when tokens are stored in user accounts so you will need to rip it apart a bit if your tokens are stored somewhere else (like in my case)
I'm totally new to SAML. I want implement SSO for my ASP.NET Website. I got the SAML assertion from my client. I would like to know what are all other requirements I need to get it from my client and what setup I need to implement at my end.
Can anybody help me out in this.
Thanks in advance.
The first thing that I would do is avoid writing the SAML code yourself. There's plenty out there. #Woloski (above) has some. My company has some (I work for the company that makes PingFederate). There's some open source stuff, too. I've seen good connections from KentorIT authServices. If this is your first foray into SAML, then my bet is that ADFS is way overboard. I'll be honest, the groups we see most commonly at Ping is when they decide to go "all in" with SSO. The first one or two connections are easy. Tehn it becomes a management nightmare rapidly thereafter. The reason I say to avoid writing your own, is because there are a LOT of nuances to SAML, with massive pitfalls, and headaches you just don't need.
As the service provider (SP), you need to tell your client (Identity Provider, or IdP) what "attributes" you need from them to properly connect their users to their account in your application (maybe a username?). In addition, you can ask for additional attributes to ensure their profile is up to date - phone number, email, etc. It's up to the two of you to determine what you need (and what they'll give you). Obviously, they shouldn't send social security number, if you have no need for it.
You also need to decide if you will do SP initiated SSO (will the users get links to documents deep inside your app?), or if just IdP initiated (Or will always just come to the front door?) will suffice. What about Single Logout? Do you (or they) want to do that? [Personally, I suggest NO, but that's a different topic]
What about signing the assertion? Your cert or theirs? If you're doing SP-init, do you need to use their cert or yours for signing the AuthnRequest? Do you need encryption of the assertion, or maybe just a few of the attributes?
Generally, you do all of this with a "metadata exchange". You give them your metadata that says "this is what we need". They import that metadata to build a new connection, fulfilling the attributes your app needs with calls to their LDAP or other user repository, as well as doing authentication (if required). They finish building their connection, and export THEIR metadata, which you import to build your connection (thereby making sure you all agree on certificates). You hook it to your app, and away you go.
I make this sound easy. It is, and it isn't. Rolling your own can mean issues. Lots of them. With some being so minute that it takes pros hours (and days) to see it. When it works, it works, and well.
HTH -- Andy
you can use something like ADFS to accepto SAML Assertions. ADFS gets installed on Windows 2008 or 2012.
You would need to ask your customer
the signing certificate public key and
the sign in URL.
Then you would create a "Claims Provider Trust" in ADFS and enter those details. Then a "Relying Party Trust" that represents your application. Finally you would have to configure your application with ADFS using WIF. This blog post have more details:
http://thedotnethub.blogspot.com.ar/2012/12/adfs-20-by-example-part1-adfs-as-ip-sts.html
Also you can use Auth0 to accomplish the same without setting up any software on your side (disclaimer: I work there).
I'm using this link https://www.google.com/reader/api/0/stream/contents/feed/FEEDHERE?output=json&n=20
to fetch feeds using Google's algorithm. As you can see I'm not adding any other parameters, just fetching the returned data in JSON format. My app will be heavily used hopefully and if I send a lot of requests to this link, will Google block my access or something?
Is there anything I can include, like userip, url for my app (so if they have problem to just contact me) or something else?
The most basic answer to your question is that Google will change its Terms of Service whenever it likes, and you've got no say in the matter. So if it's allowed today, it might not be allowed tomorrow, at Google's whim.
On this issue, though, you seem fairly safe. From the Terms of Service (these is the general document, since Reader doesn't seem to have a specific one):
Don’t misuse our Services. For example, don’t interfere with our Services or try to access them using a method other than the interface and the instructions that we provide.
Google provides RSS and Atom. They provide these feeds, so I assume they expect that they'll be used. They don't say that it's a misuse to point someone else at those feeds, so it looks OK for now, but they could add such a clause at any time.
All online services are subject to the terms and conditions of the providers of those services. So, as others have said, they may be ok with your use today, but they can change their mind any time down the line. I doubt including a URL or email or contact info will help anything, because when these services change, they don't notify every user of the service, they just announce the change publicly, and usually they give several month's notice in order to give users a chance to adapt their applications, but this is not standardized or enforced so there is no guarantee. One example would be the fairly recent discontinuance of the Google Finance API (for which no replacement has been announced).
The safest approach would be to design your app such that this feature that uses google's functionality is decoupled as much as possible from the rest of your app, so that, when or if the availability of the service changes (ie it's no longer available at all) you can adapt your app to use some other source for the feeds with minimal impact to the rest of the app. Design for change and plan for the worst.