Routes not registered about laravel-aws-worker HOT 6 CLOSED

@Andreyco it's actually done on purpose - to protect production (public) websites from users calling /worker/queue or /worker/schedule directly. The idea is to set worker environments (APP_ENV) to something like production-worker instead. I will put this in the README.

If you have a better idea of how to isolate these 2 special routes from public - share :))

from laravel-aws-worker.

I added this in README

Alternative implementation could be an extra environment variable (eg. REGISTER_ROUTES). If it's set - routes are added.

I just don't like the idea of registering the routes by default - you don't want normal users to run your jobs ;)

from laravel-aws-worker.

How I reason about Laravel worker app

• it processes long running tasks.
• it runs in its very own container/environment.
• it's not accessible from outside - only AWS daemon pushes POST requests to worker. Based on this, I don't see any reason to worry about URLs being registered in any environment. They are not accessible from outside.

Is there any possibility anyone would use this package outside of AWS Worker environment? Is it event possible/reasonable?

Also, I would not rely on env name to decide whether to register routes or not. I like REGISTER_ROUTES flag more :) But as noted above, we should be not worried about this at all (let me know if I am mistaken here).

These are my assumptions and findings, I might be wrong. I am, often :)

PS: don't take any of these notes wrong, I am so thankful for this package, it's very good! I hope we figure something out.

from laravel-aws-worker.

You are right, but very often people run the same application in both web and worker environments. Moreover, Laravel actually assumes that you are doing so - jobs are serialized on one end, and they are supposed to correctly desereliaze and run (read - have all the same classes and methods available) on another end.

Therefore, people would add this package and it would go to both worker and web environments. Hence the protection measure - to ensure extra routes don't land in public web :)

If you worker is a separate application, then there is no problem of course.

Having said all that, an environment variable seems like a more comfortable and clear way to do this. I will put this into next version!

from laravel-aws-worker.

https://github.com/dusterio/laravel-aws-worker/releases/tag/v0.1.8

I added REGISTER_WORKER_ROUTES variable and currently it's set to true by default (to avoid service interruption for existing users)

from laravel-aws-worker.

Yep, you are correct.

I have jobs with empty "handle" method on public facing app + very same job with "handle" implemented on worker app.

One one side it leads to (very low) duplications but on the other side responsibilities are clear here.

Seems line env variable + major version bump (no to break existing code) would be best solution here.

Sent from my iPhone

On 21 Oct 2016, at 01:56, Denis Mysenko [email protected] wrote:

You are right, but very often people run the same application in both web and worker environments. Moreover, Laravel actually assumes that you are doing so - jobs are serialized on one end, and they are supposed to correctly desereliaze and run (read - have all the same classes and methods available) on another end.

Therefore, people would add this package and it would go to both worker and web environments. Hence the protection measure - to ensure extra routes don't land in public web :)

If you worker is a separate application, then there is no problem of course.

Having said all that, an environment variable seems like a more comfortable and clear way to do this. I will put this into next version!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

from laravel-aws-worker.