We are in the process of designing a front-end application with Angular which will call a jBASE server through RESTful APIs. APIs are created from jBASE component called jAgent.
Does jAgent support creating and verifying JWTs?
If not, what is the best way to handle authentication/authorization for the Angular application?
If we need to use JWTs, do we have to use a authentication middleware application (.NET Core or node.js) for that?
Great question! At the moment there is no handler within jAgent and our recommendation is to implement this, and advanced web server/API gateway technology by way of other applications like HAproxy or Kong.
An expansion of jAgent functionality to include things like this is something we're still considering but keep in mind, the power of jBASE lies in its native interactions with the host OS. Since there is no virtual OS layer it can be easier to plug and play off the shelf things to fill in for additional functionality, which gives you the flexibility to bring your own tooling.
In summary:
Not at the moment
Using an off the shelf package to act as your API gateway
Subject to the package you choose
That relegates jAgent to management of the API layer as it exists on the PICK/jBASE side while the off the shelf package manages your API security layer.
One other note for you--I noticed that you included a link to the old jBASE docs hosted on HelpJuice. It's worth mentioning that we've migrated those docs to docs.zumasys.com. You'll find the docs there to be more up to date, and also completely open sourced--part of the migration included their move to a GitHub repo, where we're happy to take community contributions.
For reference, the article you mentioned is available at https://docs.zumasys.com/jbase/connectivity/jagent/introduction-to-jagent-rest-services/.
Update:
One of our engineers has a program that will use openssl to generate the tokens for you, which you can find at https://github.com/patrickp/wjwt.
You will need openssl installed on the machine and in the path.
The WJWT.TEST program shows the usage. The important piece is the SECRET.KEY which is your internal KEY you use to sign the payloads.
When a user first authenticates you create the token with SIGN. Claims are any items/fields you wish to save/store. Do NOT put sensitive data in here as it is viewable by anybody. The concept is we sign this with our key, give it back to the client. On future calls the client sends the token and we pull it and call the VERIFY function which basically re-signs the payload and validates the signatures match. This validates the payload was not manipulated.
Activities such as expiration you would build into your code.
Long term we plan to take this library and refactor the code into our MVDB Toolkit library with more functionality. That library is something we provide to jBASE customers at no additional charge.
Related
I want to mock api calls from my application, and host the mock, so my tests can work without calls to real api. There is a service called restbird which does exactly that, but it is far from ideal for me. If you want to collaborate you have to host the service by your self. Also it has some errors like not displaying history of calls, or when it sends server errors for no reason. I want a service more robust than this one.
The only service that I think might be a good fit is SwaggerHub, it seems robust, it has virtual servers, and overall it is very popular. But the only problem is that I cannot find a way to record api calls from my application. So how can I record api calls for SwaggerHub?
There does not currently exist any functionality within SwaggerHub itself to record API calls made from the Swagger UI module within the tool. This is a limitation of the open-source Swagger UI tool.
What I can recommend is you use the Swagger Inspector tool. The Swagger Inspector can be used to make API calls from a client, save both the request and the response, and even generate an OpenAPI file for you based off the request/responses. If you create an account and sign in, you can even save your API calls to a collection to use later.
Swagger Inspector: https://inspector.swagger.io/builder
It may also be worth considering using ReadyAPI's Virtualization module to handle this use case. With ReadyAPI Virtualization you can record transactions from a browser, build mock services from the recorded transaction or an existing API definition, and then host the mock service using VirtServer.
ReadyAPI is a part of SmartBears API lifecycle products, so there are integrations between the two tools. For instance, you can port APIs from Swaggerhub into ReadyAPI directly and you can use mock services built in ReadyAPI to do dynamic mocking in Swaggerhub.
You can find more information about ReadyAPI Virtualization here: https://smartbear.com/product/ready-api/api-virtualization/
I realise this is a very late response to this thread, but hopefully this information comes in handy.
I am currently evaluating the framework "wolkenkit" [1] for using it in an application. Within this application I will have a user interface for tenant-based data management. Only authenticated users will have access to this application.
Additionally there should be a public REST API following common standards and being callable by public (tenant security done with submission of a tenant-based API Key within the request headers).
As far as I have found out, the wolkenkit REST API does not seem to fit these standards in forms of HTTP verbs.
But as wolkenkit at all appears to me as a really flexible and easy-to-use framework, I wonder how to basically implement such a public API.
May it be e.g. a valid approach to create an own web application which internally connects to the wolkenkit backend? What about the additional performance overhead then?
[1] https://www.wolkenkit.io/
In addition to the answer of mattwagl, I would like to point out a few things that you may be interested in.
First of all, since wolkenkit is based on CQRS, the application has a separate API for writing and reading. That means, that if you send a command (whose intent is to change state) this goes to the write API. If you subscribe for events or run a query, this goes to the read API.
This again means, that if you send a command, it's up to the write side to respond to it. As the write side is not meant to return application state, all it says is basically: "Thanks, I have received the command." To get the actual result you have to wait for the appropriate event, which means subscribing to the read API.
In the wolkenkit documentation there is a nice diagram which shows this in a clear way:
If you now add a separate REST API (which actually fulfills the requirements of REST), this means that you need to handle waiting for the result internally. In other words: Clients in wolkenkit are always meant to be asynchronous, REST is not. Hence it's your job to handle the asynchronous behavior of the wolkenkit APIs in your REST API. I think that this is the hardest part.
Once you have done this, you will have a synchronous REST API, and of course it will have some overhead. But I think that since its overhead is limited to passing through and translating network requests, it should be negligible.
Oh, and finally, there is another thing that you have to watch out for: Since REST as it was meant originally relies on the HTTP verbs to transport semantics, you need to map GET / POST / PUT / DELETE to the semantic commands of wolkenkit. As long as this can be done 1:1, everything's fine – problems start when there are multiple commands that (technically speaking) do an UPDATE.
PS: I'm also one of the developers of wolkenkit.
PPS: However you are going to solve this, I would be highly interested to hear from you! It would be very great if you could share your experiences with us, as you are most probably not the last one with this idea. If you want to contact us, the easiest way would be via Slack.
wolkenkit applications can be accessed using an HTTP- and a Websocket-API. These APIs are both provided by the tailwind module that wolkenkit uses under the hood. In the tailwind repo you can find a very simple documentation of the available HTTP routes.
You're right, the wolkenkit HTTP-API is not a classic REST-API. It's more RPC-style which in our experience is a good fit for applications. There are only 3 routes that your clients/tenants need to support: /v1/command (POST) is used for issuing commands. The commands you post should follow the command schema. /v1/events (POST) can be used for streaming events to clients. These events will follow the event schema. Finally you have /v1/read/:modelType/:modelName (POST) to read models. You can simply use HTTPie to test these routes.
Authentication of these APIs is currently done using OpenID-Connect. There's a very detailed article on how to setup authentication using Auth0. I'm not quite sure if this fits your use-case but you could basically use any Authentication Service that follows this standard or that is able to issue JWT tokens.
Finally you could also build your own JavaScript client-SDK that runs inside browsers by building a module that uses the wolkenkit-client-js under the hood. This SDK can just use the same API as any other client to connect to your application.
Hope this helps.
PS: Please note that I am one of the authors of wolkenkit.
After reading the official guide on how to structure projects and going through various (1, 2, 3 to name a few) examples and projects I can't help wondering whether my approach of structuring my REST-API server app is structured properly.
What is the API meant to do?
POST /auth/sign-in
Accepts a username and password and issues a JWT (JSON Web Token).
GET /auth/sign-out
Adds the JWT to a blacklist to invalidate the auth session.
GET /resources
Retrieves a list of all resources.
POST /resources (requires valid JWT authentication)
Accepts a JSON body, creates a new resource and sends out an email and notification to everyone about the new resource.
What my project looks like
Currently I'm not creating any libraries. Everything is sitting in the main package, the overarching server setup with routes etc. all done in main.go. I didn't go for the MVC pattern found à la Rails or Django to avoid overcomplicating things just for the sake of it. Also my impression was it doesn't really comply with the recommended structure for commands and libraries as described in the guide already mentioned above.
auth.go # generates, validates JWT, etc
auth-handler.go # Handles sign-in/out requests; includes middleware for required authentication
mailer.go # Provides methods to send out transactional email, loads correct template etc.
main.go # set up routes, runs server; inits mailer and notification instance for the request context
models.go # struct definition for User, Resource
notifications.go # Provides methods to publish push notifications
resource-handler.go # Handles request for resources, uses mailer and notifications instances for the POST request
What should it look like?
Should routes be separated? What about middleware? And how do you deal with interfaces to 3rd party code – imagine mailer.go in the outlined sample app talking to Mandrill and notifications.go to Amazon AWS SNS?
I can share a bit from my own experience.
In application code:
as opposed to library code, separating into packages and sub-packages is less important - as long as you don't have too much complexity in your code. I mostly design apps as integrating self contained libraries, so the app code itself is usually rather small. In general, try to avoid package separation if you don't really need it. But don't just slap tons of code in one package - that's also bad.
but don't have general packages like "util", they soon start to accumulate baggage and suck. I have a separate repo for generic utils reusable across projects, and under it each utility API is a sub package. e.g. github.com/me/myutils/countrycodes, github.com/me/myutils/set, github.com/me/myutils/whatevs.
Regardless of the package structure, the most important thing is to separate internal APIs from handler code. The handlers code should be a very thin layer that handles input, and calls an internal, self contained API, that can be tested without handlers, or tied to other handlers. Looks like you're doing this. Then you can separate your internal API into another package or not, it doesn't really matter.
When you're deciding what parts of the code should be separated into libraries, think in terms of code reuse. If this code will be used only by your app, there's no point in that.
I like to wrap integration with third party APIs in an interface that is defined in a secondary package. For example if you have something like sending emails with AWS SES, I'd create a pakcage called github.com/my_org/mailer, with an abstract interface, and under it an github.com/my_org/mailer/ses package that implements the SES integration. The application code imports the mailer package and its interface, and only in main do I somehow inject the usage of SES and integrate things together.
re middleware - I usually keep it in the same package as the API itself.
What are some web apps that allow me to play with any REST APIs visually (by clicking) and also get some code generated (in any language) that captures what I have described visually?
Similar to Swagger or Google API Playground but allows me to talk to anything that speaks REST (assuming I have the proper auth credentials and I know what messages it understands).
Bonus points for something that can also "discover" what messages are understood, given a URL endpoint.
Microsoft has 2 that I know of
OData API explorer
The data market service explorer (requires signing in, and then you can access free data sets)
Considering that REST API's are going to follow their own conventions, terms, and have their own documentation (hopefully), this is an impossible problem. If you restrict your quest to visualizing API's that follow a "standard" form of self-documentation (see REST web service WSDL? for some hopeful scenarios) you might be able to accomplish this.
Or you can use something like http://www.programmableweb.com/ to discover tutorials, tools, examples, and mashups of various existing APIs.
You could mock an API at http://apiary.io/.
You could explore and existing one through tools (e.g. REST Console for Chrome)
What you can't have, is one-size-fits-all explorer for "every possible REST API." Some APIs follow conventions that others don't.
apigee and apihub (now part of mulesoft) are two that I frequently visit. Of the two, apigee is my preferred provider.
One of the reasons that you're not going to see a lot of websites like this is because of the same-origin policy. This means that you can't access a RESTful API located at api.google.com from a web app running at, say, www.restfiddle.com without sending all the API traffic through restfiddle.com's servers. Sites like JSFiddle can exist (and are used widely) because all the processing is done on the client side.
Browser plugins, however, are exempt from the same-origin policy. If you're using Chrome, try Postman. If your REST client doesn't need to be web-based, check out SoapUI. IntelliJ IDEA has a nice REST client as well.
Try Restlet Studio, it's the only visual API designer I've found, and seems pretty good, it imports and exports swagger & RAML.
http://studio.restlet.com/
My company is reworking its API and wants to make everything RIGHT for this time ;) Thats the setup...
We are delivering data to clients over the internet.
Clients are mobile handsets like iPhone, Androids, J2ME, Blackberry...
The server is coded in Ruby on Rails
We want to achieve through a framework...
Take use of ActiveResource on the clients.
The framework should do the connection (REST), parsing and (dynamically) providing of models
Licence must be open source.
Authorization shall be included. We use OAuth and need to deliver the Access Token on any request. Maybe as parameter or in the HTTP-Header?
HTTPS/SSL support
Pagination and Relationships (with lazy loading) support would be great! Otherwize the framework must be able to be adjusted for these things.
We already have found following frameworks and kindly ask you guys to evaluate them. Maybe one of you used some of them or something different...
Android: RESTProvider from Novoda / Carl-Gustaf Harroch
Providers offer an abstraction from data sources on Android and the RESTProvider Automatically parses RESTful API responses into a Provider. RESTProvider is an implementation of all commonly re-implemented functionality when dealing with web services in Android. Users can seamlessly interface with any Web Service API which provides JSON or XML as a response. To query a RESTProvider in an activity a user need only specify an endpoint and then query an APIs RESTful functions. RESTProvider also handles all HTTP querying & caching.
Haven't found much documentation other than that
Provides caching as well
Release + Documentation is planned for early 2011
iOS: http://iphoneonrails.com/
Lib for communication between iOS and Rails
RESTful and "ActiveResource"-based
includes XML/JSON Parser
free licence
pagination?, android?, lazy loading?
Android: Hand made approach with the use of cursors backed by a SQLLite DB
intended to be very performant and best practice of Android
uses cursors
Android: Spring Android Rest Template Module
Spring's RestTemplate is a robust, popular Java-based REST client. The Spring Android Rest Template Module provides a version of RestTemplate that works in an Android environment.
Android: You always should take a look at this video of Google IO 2010 when thinking serious about REST
Android: Feed Framework
com.google.android.feeds
A collection of classes to help you build content providers. The framework is specially designed to help connect your application to Web APIs.
I am the author of the RESTProvider. Still very early stage so I would not recommend to use it in production. I have been using it on several projects which are in production but I adapted most the code to specific needs. I will try to get a public stable API by the end of the year.
In regards to reworking the API, I would suggest the following:
Use GZip compression
Use ETags for caching
Use standards with no modification (I saw cases where the naming changed from oauth_token to my_token which makes most library useless without modification) - OAuth/REST
Use creation/modified timestamp and remote ids for all objects in order to enable caching client side (SQLite conflict clauses):
{"myobject": {"createdAt": xxxx, "rid": "hashvalue"}}
4a. Use a good way to identify the object returned for user/activity/application: opensocial uses "application id" + "user id" + "activity id"
Prefer JSON over XML
Prefer simplicity (lowest depth possible)
Return the full object with the one to many relationship within that object:
{"parent":....
"has": {"full object not just the ID"}
}
Don't return IDs only ( "category": [ 2,3,4] should be "category": [{"name": "testing", "id": 2},{"name": "production", "id": 3 }} )
Consider each call to be independent of each other (i.e. I should have enough information for call http://test.com/object.json to populate my views)
For documentation:
1. provide test servers
2. provide cUrl for testing
3. provide sample scripts in java/php/ruby etc...
That s all I can think for now. I might add ontop of this as I come with more suggestion.
I'd recommend taking a look at RestKit for iOS
High performance, threaded network layer with a simple API for request/responses
Object mapping system for mapping remote payloads into local objects declaratively (including relationships)
Integration with Core Data for providing a fast local cache of remote data with synchronization capabilities
Support for generating a seed database from a series of JSON payloads
Specific support for integrating with Ruby on Rails backends (RKRailsRouter)
Apache licensed
Used in production in a number of excellent apps (i.e. Gate Guru)
Just to add to Spring RestTemplate choice. Here is link for SSL https calls. Hope this helps others. Was looking for this solution a long time.
http://www.makeurownrules.com/secure-rest-web-service-mobile-application-android.html