Move /models /routes to explorer middleware

[ritch]

This issue raises the concern for these routes always being available. They should not be available from a vanilla use of loopback.rest(). Instead whatever is using them (I'm assuming explorer) should add them or turn them on.

[bajtos]

Note: loopback-explorer does not use this routes, it has it's own routes for ages. If there was not a backwards-compatibility concern, I would say the routes can be immediately deleted.

I am proposing to add a flag that will control whether these routes are added or not. This new flag should be:

• Enabled by default to preserve backwards compatibility.
• Deprecated from the beginning, so that users are warned about this problem. Use depd for deprecation, that's what express uses too.
• Disabled in the configuration scaffolded by slc loopback via loopback-workspace. That way new applications come without these routes.

[greaterweb]

Thanks guys for looking into this.

I can take a stab at the first two items @bajtos has suggested. Depending on time, I might be able to look into the loopback-workspace one as well.

I'll be sure to include a few tests as good measure.

[greaterweb]

Enabled by default to preserve backwards compatibility.

Trying to think through a config option that is meaningful and concise for this one, two options

• disableLegacyExplorer - (boolean, false by default) seems appropriate but is a bit lengthy - true disables the routes, false or omitting the option keeps them enabled
• legacyExplorer - (boolean, true by default) this shorter option seems better - false disables the routes, true or omitting the option keeps them enabled

Thoughts?

[greaterweb]

Work completed to resolve this in PR. Though I wonder if we should improve the middleware to limit only GET requests.

[bajtos]

+1 for legacyExplorer, disableLegacyExplorer=false is a double negative which is better to avoid.

Depending on time, I might be able to look into the loopback-workspace one as well.

This part is easy, just add a new entry to templates/components/api-server/component.js and a new unit-test to test/end-to-end.js.

[greaterweb]

@bajtos, no problem. I can make the update to the loopback-workspace project

[crandmck]

Does this require any doc updates or additions?

Currently, to disable API Explorer, docs just say to delete explorer.js boot script: http://docs.strongloop.com/display/LB/Security+considerations#Securityconsiderations-DisablingAPIExplorer Will that change with this?

How is the legacyExplorer option exposed?

[greaterweb]

The instructions for disabling the API Explorer remain valid. This issue was to address two routes remaining exposed which have not been used by the API Explorer for some time.

The legacyExplorer option is an addition to the the config.json file. When making the upgrade to v2.14.0, it's is a good idea to add "legacyExplorer": false to your config. I'm sure we'll see an update soon to the config.json documentation.

[crandmck]

I'm sure we'll see an update soon to the config.json documentation.

Heh, that would be my job ;-)
Please review to see if I explained it correctly:
http://docs.strongloop.com/display/LB/config.json#config.json-Top-levelproperties
Thanks!

[greaterweb]

Ha! Sorry, I did not know :-)

Thanks for all of the great work documenting, I imagine it's a decent challenge keeping up with all StrongLoop has going on!

Your addition to the docs looks good, two small changes though:

Set to false to disable old routes /models and /routes routes that are exposed, but no longer used by API Explorer; use true or omit the option to keep them enabled.

Thanks!

[crandmck]

Thanks for all of the great work documenting, I imagine it's a decent challenge keeping up with all StrongLoop has going on!

You're welcome... and, yes, it does keep me quite busy :-)

Thanks for catching the typo! Fixed...

[bajtos]

I am closing this issue as fixed by #1135.

@ritch feell free to reopen if you have any objections.

[gausie]

It would be good to be able to hit a model endpoint with the OPTIONS verb and get the equivalent of its entry in /models.