Running deploy from the examples/cognito directory I get the following error.

MalformedPolicyDocument: Invalid principal in policy: "SERVICE":"cognito-identity.amazonaws.com" status code: 400, request id: a2de5b72-7fa6-11e8-b8c9-0f4f651e0f50

I'm hitting this error in the cognito callback function. Looks like it's coming from here https://github.com/tmaiaroto/aegis/blob/master/framework/cognito_client.go#L287

I created a blank project using aegis init but am getting an error when trying to deploy.

$ aegis deploy There was a problem building the Go app for the Lambda function. exit status 1

Is there anything I should change in order to deploy this project?

More and more there are needs to deal with sensitive credentials. Be it a Cognito secret key or database connection info. Not everything can be handled by IAM and SDK calls.

I made a project a long while ago called discfg. That exposed an HTTP API interface and used DyanmoDB as well. I'm thinking something simpler.

I'm thinking a new command for the Aegis CLI that lets one read and write key values to perhaps just S3. This would avoid the use of DynamoDB (just another thing to provision and such). The reason being that these config values won't often change. There's no concern with write speed. Read speed? Ehh, should be ok. Especially considering many of these variables will only be read at start time. Warm Lambda invocations won't be affected at all.

The CLI would expose three commands: read, readFull, and write

It would use KMS to encrypt the stored values in S3. A bucket would need to be configured (aegis.yaml). The file name will come from configuration too (or conventionally be the name of the Lambda, though the ability to change that without losing config path is preferable).

So all the Lambda would need at build time is the bucket/path. The deploy command would have already set up permissions to use KMS. Then it's just a matter of a simple helper function in the Lambda function to get the values.

These would be as simple as setting environment variables. Perhaps the helper even pulls the entire file and sets as environment variables. So the process can be the same both when testing/developing locally and running in AWS. Or so that environment variables can be optionally used instead. It keeps things a bit more standard and flexible. Think CI tools, etc. Things that might not have KMS access yet still need to run the app or run an integration test, etc.

The read and readFull commands are nice too. The normal read would only show part of the stored value, with asterisks protecting the bulk of it. For example, DB_PASSWORD=a1kj******ak should be enough for someone to quickly see what was currently set and if it's correct (in most cases). While a readFull command would show the value completely unencrypted. This is just security convenience. If someone is in a position where they don't want everything to appear on their screen unencrypted, they have a choice now.

What this whole thing does though is it makes it harder for developers to push sensitive credentials to online repositories. The aegis.yaml file should theoretically be able to contain nothing sensitive. The Lambda environment variables and API Gateway stage variables set there shouldn't be sensitive passwords or keys because it's so incredibly easy to commit that aegis.yaml file. Many people will want to commit that file too instead of sharing it among people because it contains the function name, memory allocation, API name, etc. It should be able to be pushed to a public repo without concern.

I'm not keen on making some sort of dot file that magically sets variables because again we're in the position of accidental publishing. There's still the need to then share that file with team members.

S3 is central. It's easier to provision than DynamoDB and there's no management of capacity units to consider. All team members should have an AWS account with access to S3 and KMS. The specific KMS key and S3 bucket needed in this case. It provides one central point to control access to the credentials. It leaves absolutely no way to accidentally publish sensitive information either.

I ran:

aegis init aegis deploy There was a problem building the Go app for the Lambda function. exit status 1

Is there something I'm supposed to do after init?

I see in one of the examples that you can set an api->resourceTimeoutMs, but this doesn't seem to change the Basic Setting timeout in Lambda:

Please let me know if there is a setting to change this.

Thank you

API Gateway now has binary support. It just needs to know which content-type headers to treat the media type accordingly. This should be configurable.

Is it possible to create a custom zip and include non go files like templates and such?

I saw in the config file that you can provide a custom zip file, which i created by generating the go binary and placing it in a zip with my template but no dice.

Any suggestions?

This is a big one, but it's very common and important for most apps.

There should be handlers for each trigger described here: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-lambda-trigger-examples.html

There should be middleware that can be used with the router.

We can return HTML pages with Aegis actually. So either work with JSON to allow a custom app to design sign up forms, etc. Or return a default simple HTML form/template. I imagine 80%+ of the time apps would make all the sign up forms, etc. However, using redirects or iframes even could be valuable, especially for speed. This raises an interesting concept -- what about HTML templates held in S3? Aegis could load those to render. So design can be customized to a good degree. Of course lengthy forms for profile updates, etc. would be something to work on later or just completely out of the equation. Aegis hosted HTML through API Gateway could simply be simple signup/login. No extra form fields about phone numbers, birthdate, etc. It's much better to use CloudFront for hosting and not S3 (assuming templates are hosted there and not bundled with the Lambda...but actually why not bundle with deploy?) through Lambda through API Gateway. Though for speed/convenience...Something to think about.

Pools have to be created outside of deploy. They can't have their attributes updated once created - so having a list of attributes in the config would be weird because they'd be a one time use. Also, it's just a lot here. It's bloating deploy. API Gateway and roles and such made sense (especially given the usage of API Gateway was opinionated), but maybe even some of that could benefit from separate commands for certain things. The first pass of Cognito in aegis could certainly require all Cognito setup to occur outside of the too. Using the web console is easy enough. Though a comprehensive CLI tool (that is likely to be quite opinionated) is a long term goal.

Much like the other handlers, there should be a trigger from incoming e-mails. "Handler routing" perhaps based on e-mail address or even domain.

This one is probably more involved with the configuration than other event sources.

https://aws.amazon.com/blogs/aws/new-receive-and-process-incoming-email-with-amazon-ses/

Sorry if I missed anything but How to install this project. I 've search for go and npm package but there was no result. Do I have to clone and build this project to have a binary file for aegis CLI ?

AWS recently released a better option for API Gateway and Lambda. Cheaper too. Also parses JWT which could be a nice option as well.

It better matches how Aegis works. Still need to double check a few things (like stages), but may be a much better fit. Also realizing that there's no rate limiting, it may just be an option.

https://aws.amazon.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/

Changes in various things can create issues from time to time. Having an integration test to ensure basic build and deploy works would be great. Having it periodically run automatically would be better.

Maybe run this from a Lambda? 😀

I'd really like to add AppSync support. Then have a router for resolvers.

• handle resolvers with a new router
• import/export/push/sync with AppSync

The Amplify CLI toolchain is great and all but, it's very heavy and does a lot. It also uses CloudFormation and as such there's a lot of stateful issues and limitations. For example, there is no ability to import and existing GraphQL AppSync API into the toolchain. However, the SDK has everything needed: https://docs.aws.amazon.com/cli/latest/reference/appsync/index.html#cli-aws-appsync

I see no tool out there that pulls down your AppSync API, allowing you to update the VTL and then push back changes. So if something was created via the web console for example...you're hosed. Amplify CLI wouldn't be able to deal with it. A sync (no pun intended) would really help.

I'm using AppSync GraphQL more and more and will replace a lot of my API needs with it. Not all, but a lot. Auth checks using Cognito are great and you can make multiple queries in the VTL templates (transactions etc) so checking for authorization based on data in RDS or something is pretty easy too. This eliminates a tremendous amount of need for Lambda functions.

Want to send an e-mail if a user invites another user to their group in your app? Sure, you're looking at Lambda. So there's no way to completely avoid it but, AppSync is a very powerful thing that people are missing out on and aren't connecting all the dots (and the examples don't really show the potential either really).

So being able to manage this from aegis fits in pretty naturally. Funny enough, one could use aegis then to build an entire API and never write any Go code at all. Technically speaking. Practically, of course you'd have more going on and would write some Go functions.

I'm going to keep a running list of 3rd party add-on ideas here. These will not be part of this repository because all 3rd party things will be separate packages. Aegis only deals with AWS. However, there is a sense of interop and a desire to use other services.

Tracing

• Opentracing: http://opentracing.io https://github.com/opentracing/opentracing-go

This one may even make sense to include (since logrus is) in the core framework package. It's a vendor neutral bridge, however it does not include X-Ray. So on the fence about it. Also makes me think about moving logrus out on the other hand. Regardless, I think this is very important and I think it can use the existing TraceStrategy interface to adapt calls; perhaps some additional methods on top for it specifically.

Auth

• Auth0 https://github.com/auth0-community/go-auth0

This is such a popular service it seems like there should be a 3rd party package to work with.

The idea of "Services" are really just handler dependencies that get injected, but also can be configured. This configuration happens with a closure that receives context and the event. So it allows for a great deal of flexibility with what gets injected into a handler.

Currently only the Cognito service (which is a more involved "helper" of the sorts) is used. The ability to add custom services is sorta there -- there's a Custom field on the Services struct, but it's not fully implemented. That is, nothing will get configured.

For example, look at what happens with the Cognito service:

if sCfg, ok := a.Services.configurations["cognito"]; ok && a.Services.Cognito == nil {
    cognitoCfg := sCfg(ctx, evt).(*CognitoAppClientConfig)
    cognitoCfg.TraceContext = a.TraceContext
    cognitoCfg.AWSClientTracer = a.AWSClientTracer

The current Lambda context and event are given to the configuration function (held on a configurations map). This allows the Cognito service to use that context and event to configure itself.

Currently, users could write some sort of configuration "New()" function and run it in each of the handlers they wish to use context and event data from...But that's not so much dependency injection. That's taking the event and instantiating a new service after the fact. We can make it a little cleaner. Not saying it's the only way it should be done or could be done...But it provides another option that may become more important when it comes to use 3rd party packages.

First off: Refactor the check for cognito service configuration. That should be in its own function that not only checks for that, but also other services.

Second: Also take into account Custom user services.

The following is how the Cognito service gets configured: AegisApp.ConfigureService("cognito", func(ctxcontext.Context, evt map[string]interface{}) { ... })

That should already work well for every other service in the future as well. Custom services should be something like ConfigureService("custom.myservice", func...)

That function adds to the configurations map which gets used in the base aegisHandler(). It just needs to work for more than just the Cognito service now.

So the groundwork is all in place. There's a clear path on how to implement these things, it just needs to happen. It was never really added. Though the intent for custom services was always there.

The priority? That really is hard to say, because there are ways to use and configure services for your handlers already. Just do it inside the handler. This is mostly an enhancement and quality of life improvement that allows you to write less code (or potentially share more code with others).