I'm writing a custom service worker and would like to get a list of these endpoints to cache.
It seems like just iterating the filesystem is a good starting point, but some of the endpoints don't seem to map to files.
next-pwa appears to get this info client side using this:
const data = window.performance
.getEntriesByType('resource')
.map(e => e.name)
.filter(n => n.startsWith(`${window.location.origin}/_next/data/`) && n.endsWith('.json'))
The reason I'm not using next-pwa is I could not get it to work and am experiencing far more predictable and transparent behavior using the ServiceWorker API directly.
Our company uses Gravitee. I have my ML written in Python. I need to make available via API.
How can I do it? I think I can use FastAPI to expose my code as an API. Will it be possible to "marry" gravitee and my part? Would it be better to use something else instead of FastAPI?
Thanks for any advice
If I understand correctly, yes, you can create an API with FastAPI like:
from fastapi import FastAPI
app = FastAPI()
#app.get("/")
async def root():
# call you ML python code here
return {"message": "It's a cat!"}
Secondly, deploy it somewhere to be able to call your API internally in your company. Which mean that you should call your API like:
$ curl 'http://mlapi.internal.mycompany.com/'
{"message": "It's a cat!"}
And then, register your new API into gravitee like explain here and for example configure the rate limiting to manage your bill related to the resource needed by your ML API ;)
Note that if you also have an Access Management available, you can manage authentication without implementing it.
Hope it's help.
Written the Integration test case for testing Corda Flows through API class as:
val api=ProjectApi(mockNode1.rpcOps)
val message = "some input message"
val resp: Response=api.publishSSI(message)
assertEquals(resp.status, 201,"Failed to publish SSI")
But getting CURRENT_RPC_CONTEXT.get() must not be null exception while starting corda flow inside api.publishSSI() method.
what could be the cause?
You need to use the RPC client API to connect to the node. You can find more details here: https://docs.corda.net/tutorial-clientrpc-api.html
You can't test the API by manually constructing it in this way. When the API is set up, some additional context is passed in, which is lacking here.
Is there anyway to determine if the Rocket.chat app is running in desktop or browser?
Thank you in advance. :)
You can look at server environment variables using a line like this:
console.log(process.env.TZ);
If you need to access that from the client, you can do this in your client code:
console.log("TZ = "+Meteor.call("getEnv","TZ"));
and in your meteor methods (in the server folder)
Meteor.methods({
getEnv: function(varname) {
return process.env[varname];
},
Obviously use this with care. It is a generic method that may present a security hole. If you want to make it more secure, just write a specific method where you don't pass the environment variable name, to prevent any kind of malicious attack.
I don't want just all of my users being able to insert/destroy data.
While there is no documented way to do this yet, here's some code that should do what you want:
Foo = new Meteor.Collection("foo");
...
if (Meteor.is_server) {
Meteor.startup(function () {
Meteor.default_server.method_handlers['/foo/insert'] = function () {};
Meteor.default_server.method_handlers['/foo/update'] = function () {};
Meteor.default_server.method_handlers['/foo/remove'] = function () {};
});
}
This will disable the default insert/update/remove methods. Clients can try to insert into the database, but the server will do nothing, and the client will notice and remove the locally created item when the server responds.
insert/update/remove will still work on the server. You'll need to make methods with Meteor.methods that run on the server to accomplish any database writes.
All of this will change when the authentication branch lands. Once that happens, you'll be able to provide validators to inspect and authorize database writes on the server. Here's a little more detail: http://news.ycombinator.com/item?id=3825063
[UPDATE] There is now an official and documented Auth Package which provides different solutions to secure a collection.
On a CRUD level :
[Server] collection.allow(options) and collection.deny(options). Restricts default write methods on this collection. Once either of these are called on a collection, all write methods on that collection are restricted regardless of the insecure package.
And there is also insecureto remove full write access from the client.
source : Getting Started with Auth (thanks to #dan-dascalescu)
[OLD ANSWER]
Apparently there are working on Auth Package(?) that should avoid any users taking full control on the db as it is now. There is also someone suggesting that there is an existing solution (workaround) by defining your own mutations (methods) and make them failed if they attempts to perform an unauthorized action. I didn't get it much better but I think this will often be necessary since I doubt the Auth Package will let you implement the usual auth logic on a row level but probably only on the CRUD methods. Will have to see what the devs have to say.
[EDIT]
Found something that seems to confirm my thoughts :
Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality.
Sources of this answer :
Accessing to DB at client side as in server side with meteor
https://stackoverflow.com/questions/10100813/data-validation-and-security-in-meteor/10101516#10101516
A more succinct way:
_.each(['collection1', 'collection2'], function(collection){
_.each(['insert','update', 'remove'], function(method){
Meteor.default_server.method_handlers['/' + collection + '/' + method] = function(){}
});
});
or to make it more idiomatic:
extend meteor:
_.extend(Meteor.Collection.prototype, {
remove_client_access: function(methods){
var self = this;
if(!methods) methods = ['insert','update','remove'];
if(typeof methods === 'String') methods = [methods];
_.each(methods, function(method){
Meteor.default_server.method_handlers[self._prefix + method] = function(){}
});
}
});
Calls are simpler:
List.remove_client_access() // restrict all
List.remove_client_access('remove') //restrict one
List.remove_client_access(['remove','update']) //restrict more than one
I am new to Meteor, but what I have come across so far are these two points
You can limit what a client can access in the database by adding parameters to the find command in the server-side publish command. Then when the client calls Collection.find({}), the results that are returned correspond to what on the server side would be, for example, Collection.find({user: this.userId}) (see also Publish certain information for Meteor.users and more information for Meteor.user and http://docs.meteor.com/#meteor_publish)
One thing that is built in (I have meteor 0.5.9) is that the client can only update items by id, not using selectors. An error is logged to console on the client if there is an attempt that doesn't comply. 403: "Not permitted. Untrusted code may only update documents by ID." (see Understanding "Not permitted. Untrusted code may only update documents by ID." Meteor error).
In view of number 2, you need to use Meteor.methods on the server side to make remote procedure calls available to the client with Meteor.call.