Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SNS topic subscription isn't confirmed after being created #102

Closed
tlfbrito opened this issue Jun 20, 2016 · 7 comments
Closed

SNS topic subscription isn't confirmed after being created #102

tlfbrito opened this issue Jun 20, 2016 · 7 comments

Comments

@tlfbrito
Copy link

I've tried without success to create and subscribe to SNS with AWS provider.
Can you confirm that this is still working?

@k-k
Copy link
Contributor

k-k commented Jun 20, 2016

Hey @TiagoBrito, can you be specific? Is it not creating the topic, not subscribing to a created topic, or just not doing either?

Are you testing locally? In order for a topic to be subscribed to, it needs to be an endpoint that is publicly available so that SNS can send a POST to that endpoint for subscription confirmation. If its not publicly available, the subscription won't work.

You can use Ngrok as mentioned in the docs in that case to allow for testing locally.

@tlfbrito
Copy link
Author

@kmfk Thanks for your quick reply.
I have investigated more and reach to the conclusion that the topic is being created and subscribed but it isn't confirmed. Is there a way to automatic confirm the subscribed of each topic ? or I'm missing something ?
Thanks in advance ;)

@tlfbrito tlfbrito changed the title SNS topic isn't automatically created and subscribed in AWS provider. SNS topic subscription isn't confirmed after being created Jun 22, 2016
@k-k
Copy link
Contributor

k-k commented Jun 22, 2016

@TiagoBrito Are you doing this locally? As mentioned above, the http(s) endpoint you specify needs to be publicly accessible.

When you subscribe an endpoint to a topic, SNS will automatically send a confirmation request (POST request) and you'd need to respond with a request to a given url to confirm. That process is handled for you with this library, as long as SNS can reach your endpoint to begin with. To be clear, your endpoint must be accessible by SNS.

In local development, you typically do not have a public url unless you use something like ngrok. See: http://qpush-bundle.readthedocs.io/en/latest/usage.html#push-queues-in-development

@tlfbrito
Copy link
Author

Yes, I'm doing this locally, but the thing is: the request from SNS never reached my ngrok (but I will double check this).

@tlfbrito
Copy link
Author

I don't get it... I always get PendingConfirmation for the ngrok subscription, and the post is in the ngrok HTTP request list.
In sns endpoint I have to have a route and a controller, do I need to return something specific in this controller ?

@tlfbrito
Copy link
Author

tlfbrito commented Jun 23, 2016

@kmfk I think i finally got it...

My queue my_queue_key is different from my queue name in configurations.

Example:

    queues:
        my_queue_key:
            provider: ironmq #or aws or in_band or another_aws_provider
            options:
                queue_name:  my-actual-queue-name

In RequestListener when the type is Notification, the queue name is getted from the subject:
$queue = $notification['Subject']; (which is equal to my_queue_key )
but on the other side when the type is SubscriptionConfirmation:
$queue = str_replace('qpush_', '', $last); (which is equal to queue name (my-actual-queue-name) but not equal to my_queue_key and the onNotification method won't be trigger on AwsProvider)

@k-k
Copy link
Contributor

k-k commented Jun 30, 2016

Thanks for looking into that @TiagoBrito - just merged in a fix that should work for when the queue_name is used that will still allow subscriptions to work as intended.

@k-k k-k closed this as completed Jun 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants