apollographql / apollo-server

🌍  Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.
https://www.apollographql.com/docs/apollo-server/
MIT License
13.79k stars 2.03k forks source link

lambda: playground Server cannot be reached #2136

Closed Kcin1993 closed 2 years ago

Kcin1993 commented 5 years ago

Hi team,

Intended outcome

Using "apollo-server-lambda": "^2.3.1" expect the playground work fine.


Actual outcome

Outcome in Playground webiste right side show

{
  "error": "Response not successful: Received status code 403"
}

Check the browser console. The network's response in playground is {"message":"Forbidden"}

Note. I can test my graphQL api with curl command or aws lambda test. Only playground can not work fine.


How to reproduce the issue

Here is my serverless.yml

service: jk-bot

custom:
  BOT_FB: "jk-bot-fb-table"

provider:
  name: aws
  runtime: nodejs8.10
  stage: v1
  region: ap-southeast-1
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
      Resource:
        - { "Fn::GetAtt": ["JkBotFb", "Arn"] }
  environment:
    BOT_FB: ${self:custom.BOT_FB}

resources:
  Resources:
    JkBotFb:
      Type: "AWS::DynamoDB::Table"
      Properties:
        AttributeDefinitions:
          - AttributeName: ID
            AttributeType: S
        KeySchema:
          - AttributeName: ID
            KeyType: HASH
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1
        TableName: ${self:custom.BOT_FB}

functions:
  graphql:
    handler: handler.graphql
    events:
      - http:
          path: graphql
          method: POST
          cors: true
      - http:
          path: graphql
          method: GET
          cors: true

Here is my handler.js

const { ApolloServer, gql } = require("apollo-server-lambda");
const { botTypeDef, botResolvers } = require("./models/bot");

const typeDefs = gql`
  ${botTypeDef}
`;
const resolvers = botResolvers;

const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ event, context }) => ({
    headers: event.headers,
    functionName: context.functionName,
    event,
    context
  }),
  playground: {
    settings: {
      "request.credentials": "same-origin"
    }
  }
});

exports.graphql = server.createHandler({
  cors: {
    origin: "*",
    credentials: true
  }
});

Issue might relative


Could anyone help this situation. Any better idea?

maxhaensel commented 5 years ago

maybe you shout add the playground-route in the serverless.yaml? This works fine for me

functions:
  graphql:
    handler: handler.graphql
    events:
      - http:
          path: graphql
          method: POST
          cors: true
      - http:
          path: graphql
          method: GET
          cors: true`
      - http:
          path: playground
          method: '*'
          cors: true
taogilaaa commented 5 years ago

I also encounter this, It looks like stage inside serverless.yml is causing this issue

When we access the playground, it points to the wrong url (without stage) image

Here is the event log from the cloudwatch image image

abernix commented 5 years ago

Thanks for reporting this issue originally!

I'm going to close this issue since it hasn't received a lot of traction and could have been resolved already.

If this is still a problem, would someone who's experiencing the problem (or anyone who comes across this issue and is able to assist) mind building a reproduction of the problem in to a runnable CodeSandbox reproduction using the latest version of Apollo Server and sharing the link to that CodeSandbox in this issue?

I'm happy to re-open if this is still occurring and someone can provide a reproduction. Thanks again!

abernix commented 5 years ago

I'll re-open this since it still has a corresponding PR (https://github.com/apollographql/apollo-server/pull/2241). If any of the many folks who have 👍 'd the above comment could chime in on that PR to help clarify how it wouldn't be a breaking change (i.e. event.requestContext.path taking precedence over event.path instead of the previous behavior of the opposite), I'd really appreciate it!

Perhaps it's just a matter of how the Lambda is invoked, but I'd love some input from those that use the apollo-server-lambda package more than I do!

phoenecke commented 5 years ago

Manually adding the stage seems to at least get it working. image

DrYSG commented 5 years ago

Can you fix the page? (https://www.apollographql.com/docs/apollo-server/deployment/lambda/ I ran into the same issue as this guy about the missing /dev in the url. Took me a while to find the fix. https://stackoverflow.com/questions/57741390/error-with-message-forbidden-trying-to-query-an-apollo-serverless-lambda-se

Mellbourn commented 4 years ago

This problem seems to still be a thing. I get 403 in the playground in Prod even though I have set introspection and playground to true.

I'm using AWS SAM, so I don't have a serverless.yaml file to fix.

Prepending Dev to the URL path does nothing for me. Stage instead of Prod at least shows the playground, but still has the 403 problem.

Here is my project with this problem: https://github.com/Mellbourn/saved-counter

taogilaaa commented 4 years ago

@Mellbourn you might want to try this workaround on your exported handler

exports.graphql = (event, lambdaContext, callback) => {
  // Playground handler
  if (event.httpMethod === 'GET') {
    server.createHandler()(
      {...event, path: event.requestContext.path || event.path},
      lambdaContext,
      callback,
    );
  } else {
    server.createHandler()(event, lambdaContext, callback);
  }
};

file for context

Mellbourn commented 4 years ago

@taogilaaa that worked right away. Thank you!

glasser commented 2 years ago

In Apollo Server v3.0.1 we changed serverless integrations such as Lambda to not care about the URL path any more. (In Apollo Server v4 (currently a Release Candidate) no integrations care about the URL path, and the Lambda integration is no longer part of the core project.)) So I do not believe this is an issue any more.