I have a Rails app developed using the Spree gem. For security reasons, I'd like to disable all the API functionality - ability to make REST calls, the methods, routes. I realize that most of the API functionality cannot be invoked without an API token.
What's the best way to 'turn off' the API features?
Best way == least intrusive to existing code base
The best I've come up with so far is adding this to my host application's application.rb inside the Application class:
initializer "delete_spree_api_routes", after: "add_routing_paths" do |app|
app.routes_reloader.paths.delete_if { |path| path =~ /\/spree(-[^\/]+)?\/api\/config\/routes.rb/ }
end
What this does is immediately deletes all of the paths from the routes if they were loaded from routes.rb provided by the Spree API. It's a bit ugly but it does the job.
EDIT: I'd recommend being careful with this as Spree uses its own API in a few cases such as retrieving the list of states for a country (GET /api/v1/states)
Related
In djangorestframework, there is a browsable api. But how do I show a user an entire bird's eye view of all the possible API calls that he/she can make? I can only see one at a time right now and the user would have to already know the correct URL beforehand
i.e.,
http://localhost:8000/users
http://localhost:8000/books
http://localhost:8000/book/1/author
Thank you!
The answer is as Klahnen said. Use this:
https://django-rest-swagger.readthedocs.io/en/latest/
It works out of the box for me and it is exactly what I was hoping for.
I still maintain, though, that the term browsable API implies that there is a table of contents available for consumers of your API to see. This app is a lifesaver and perhaps it should be included!
Django-Rest-Swagger as mentioned in the accepted answer is no longer maintained.
This is a good alternative
https://github.com/axnsan12/drf-yasg
Django-Rest-Swagger doesn't support OpenAPI 3.0 and is unlikely to support it soon, so if you want an actively maintained library that supports OpenAPI 3.0 then you should use drf-spectacular. It mostly works out of the box, and you can customize it a lot.
A side note:
Your api client needs access to the internet so that it gets the swagger UI or ReDoc from CDNs. Alternatively you can serve those static files from your service with an optional additional package, the drf-spectacular-sidecar
Using Rails 4 I have an engine called Core that contains business rules and data objects for a system we're using. This is designed to be lean and in included in a few different apps.
I am creating an app that will contain some special CRUD screens for some of this core data, and I am not sure the best way to set up routing.
In other words, I want to create views and controllers for an engine's models without mounting the engine in my routes.
However, after running rails g scaffold_controller core::rep, I can't seem to get the url helper methods loaded. In my config/routes.rb:
namespace :core do
resources :reps
end
rake routes returns:
Prefix Verb URI Pattern Controller#Action
core_reps GET /core/reps(.:format) core/reps#index
POST /core/reps(.:format) core/reps#create
new_core_rep GET /core/reps/new(.:format) core/reps#new
edit_core_rep GET /core/reps/:id/edit(.:format) core/reps#edit
core_rep GET /core/reps/:id(.:format) core/reps#show
PATCH /core/reps/:id(.:format) core/reps#update
PUT /core/reps/:id(.:format) core/reps#update
DELETE /core/reps/:id(.:format) core/reps#destroy
Which seems fine.
However, upon navigating to URL: /core/reps
Showing /app/views/core/reps/index.html.erb where line #14 raised:
undefined method `edit_core_rep_path' for #<#<Class:0x00000002adf578>:0x00000002adc3a0>
Which I take to mean that the url_helpers aren't being correctly set up, and I have a growing suspicion that I am approaching this problem in the wrong way.
Is there something I am missing? Should I be trying to extend Engine Controllers in the app?
Can I use an Application's helpers with an Engine's models? Or do I have to mount the engine?
I know I can rails g scaffold_controller rep and then just patch the controller to load the data from the engine, but that doesn't seem quite right.
Have you looked at the proxy helpers bit in http://guides.rubyonrails.org/v4.1.8/engines.html#routes ?
I'm in a process of migrating Rails project into Django. Rails project was built using restful routes and it never touches the database. Instead, it simply redirects to different methods which all call an external service with the specified action method. Now, I have found a number of frameworks for django that provide restful capability plus a bunch of bells and whistles, but it's an overkill for my current case.
As an alternative, I can ignore action method in urls.py by simply providing a regex to validate urls and then parse the request method in views.py, redirecting to the appropriate method. Is this a way to go or are there any other approaches that I can look at?
Class based views look like the idiomatic way to organize restful view functions by request method.
Django snippets has several simple example implementations.
A web app written in Python is planned, Django is a leading contender as framework.
One requirement is CAC access, wihout the need to hand enter username and password. From what I can tell, CAC access is not part of the "batteries" included with Django.
As a monolithic framework (not necessarily a bad attribute) Django has a rep for being high-maintenance once you modify the core. Can I easily add CAC access to a Django site? Can it be easily maintained thereafter?
Or maybe we should consider a different Python framework?
FYI.. interesting presentation on CAC access link
You don't need to modify the core to enable this. Django supports third-party authentication backends and they're fairly easy to write - you just need to support two methods, get_user and authenticate. So your implementation just needs to perform these operations using your CAC interface, and all will work as usual.
See the documentation for details.
Edited after other answers I don't know why people are saying this is difficult in Django. Yes, many parts of Django are difficult to customise. But this is one particular part that is made very easy. I've written several authentication backends in Django and they are not only really simple, but they "just work" with the rest of the framework, including the admin. There isn't any need to modify anything else to get this to work.
I just did this today by subclassing django.contrib.auth.middleware.RemoteUserMiddleware and changed the header property to the one I had set in my apache conf. I just added the django.contrib.auth.backends.RemoteUserBackend and my middleware to the settings and it works perfectly.
Extending contrib.auth is a pain in the neck. It's the single worst thing in django. If you need highly customized auth backend, i would suggest using a different framework.
I'm willing to build a restful service using Django, I'm coming form RoR background and facing some problems that could be defined using the following questions:
What package do you recommend to use to have RESTful interfaces?
Is there a way to make nested resources like a post HTTP request to /posts/post_id/comments that adds a new comment ?
Is there a way to add some extra actions out of the CRUD set, like having extra method called notify on Post resource that works on post HTTP request.
Cheers,
1) Check out django piston.
2) Yes, you set it up in your urls list.
3) Yes, this is straightforward to do in your view.
Django Piston:
http://bitbucket.org/jespern/django-piston/wiki/Home
I would say that you can do a lot just by implementing your own views that present theirselfs in a RESTful way.
But, there is a project called piston that seems to be exactly what you're looking for: "A mini-framework for Django for creating RESTful APIs".