Is there a way to instantiate DeviceClient without a connection string in java?
Maybe with the use of ModuleClient object and DeviceClientConfig?
I do not want to set the DeviceConnectionString in the environment variables.
There is nothing that forces you to use environment variables to store your device connection string, even though that's what the code samples are using. You are free to store the connection string in whatever system suits you best (encrypted local data store, database, config file, secure module, ...).
Related
To connect to DB I have to make an API call to generate a token. Lets say I store this in environment variable $TOKEN.
Now while setting up my data source in DataGrip, how can I tell DataGrip to read $TOKEN environment variable as its value will keep on changing? Because before opening DataGrip I will make the API call to generate the token and set in a environment variable via script.
Is it possible to read environment variable as a password in DataGrip?
There is no such feature out of the box.
You can create your custom plugin to provide this kind of authorisation. That is the matter of implementing of on class - com.intellij.database.dataSource.DatabaseAuthProvider
See this plugin as an example.
Currently deploying PostgREST in AWS. When I use Fargate and just hardcoded type in the environment variables for the connection string, the machine works like a charm.
However I recently replaced these values with secrets. In the secret I copy-pasted the entire string in the value and in the environment variable I set the source from "Value" to "ValueFrom".
So the value now is:
postgres://<myuser>:<mypass>#<amazon-rds-instance>:5432/<db>
When I use this connectionstring directly in the environment variable I can easily connect, so I know the information is correct.
The logs come back with the following error:
{"details":"missing \"=\" after \"{\"postgrest_db_connection\":\"postgres://myuser:mypass#amazon-rds-instance:5432/db\"}\" in connection info string\n","code":"","message":"Database connection error"}
I also checked I have no characters in the string that need to be escaped. What can I be missing here?
So I figured it out. Unfortunately this line was it:
It is only supported to inject the full contents of a secret as an environment variable. Specifying a specific JSON key or version is not supported at this time.
This means that whenever you use the secrets as ValueFrom setting in the environment variables (when working with Fargate), the entire secret's value gets copy-pasted.
I tested this using a secret for the PostgREST schema variable. I got back the value:
{'PGRST_SCHEMA_URL': 'public'}
Whilst I was expecting it to be just:
public
This is why the configuration went bad as well. Thanks everyone for searching.
My file (c:\mydb.accbe) has protection against the shift bypass, hidden access object window protection, disabled ctrl-g, hotkey bypass protection, etc. Project is also password protected, then compiled, and encrypted.
The problem is any user with read access to that accde file can create a new access project and create an instance of the protected file of that project using this code:
Dim appAccess As Access.Application
Set appAccess = CreateObject("Access.Application")
appAccess.OpenCurrentDatabase = "c:\mydb.accbe"
Now they can call any public function of that instance, for example:
call appAccess.run("thisIsPublicFunctionIn_mydb")
I can see two potential ways to mitigate this:
1# Any potentially sensitive function would get an extra parameter that contains the 'security' code.
2# Add some security by obscurity by renaming all the functions to random numbers at the end.
Other then using a real programming language (sadly not an option), got any suggestions on how I can detect this or protect against it?
When the app is opened through automation the UserControl property is updateable, so that is not really an option.
You cannot prevent that from happening. Best you can do is use a SQL server backend, where you tightly control permissions on tables, and use procs (with permissions) to update sensitive data.
I believe that application.UserControl does something around this. I've just tried, and seems to be ok for opening via access.application
i m creating a node.js server, where i have a "notifications" module. Every request on the node server will invoke this module and i need to have a set of private variables for each separate invocation.
For example, when a request is made to notifications module, it needs to remember the user id, request time, session id, etc.
How can i do that efficiently?
If i simple declare variables in module scope, they seem to be shared for each module invocation. So, it fails in remembering every request's data privately.
What i need is each time i invoke a node.js module, it will remember its data at that time. So, please point out how can i do that?
Thanks,
Anjan
Update
The node.js server is to uses as a chat server. the "notifications" module will scan the db for new messages and send the output in json format to the client using long polling technique.
I tried to wrap the data and the functions into an object. Then each time a request is made to chat server a new object will be created and it will carry on the desired functions. But what it did is that instead of working in parallel it executes each request in serial. So, if i make 3 request to the server, they just queue up and executes one after another.
Any clue on that?
The module source code can be found here: http://www.ultrasoftbd.com/notifications.js
Thanks,
Anjan
There are a couple ways that come to mind to approach this issue:
1) Have your module export a constructor which can be called by the API users of your module to give them a new instance of an object. This way, each user will have its own object instance which has its own private variables.
// Client example.
var mod = require('myModule')
, sess = new mod.Session();
sess.method(args);
sess.finalize();
2) Have your module provide a "registry" interface to these private variables which includes an identifier unique to the caller.
// Client example.
var mod = require('myModule');
var id = mod.initialize(); // Returns a unique ID.
mod.method(id, args); // Each method requires the ID.
mod.finalize(id);
These solutions share the idea that each instance (or ID) is tracked separately by your module so that the statistics (or whatever your module does) can be computed per client instance rather than globally to the module.
I have a utility class that creates & returns a db connection:
Public Shared Function GetConnection() as OracleConnection
dim c as New OracleConnection()
... set connection string...
c.Open()
Return c
End Function
Is there any risk of concurrent calls returning the same connection? The connection string enables pooling.
Since you are returning a new connection each time you will not have any concurrency issues. If you were using a Shared method to return multiple references to the same instance, that could be a problem but that is not what you are doing here.
You are safe to use this method in this way as long as you are always returning a new instance of your database connection object each time. Any connection pooling will also work the same as it always would - you won't need to worry about your Shared method usage created problems there either.
Forget the concurrent calls issue for a moment. If there is any connection pooling going on you will absolutely have reuse of the same underlying database connections, even if they don't use the same object.
This is generally a desirable thing as opening a connection to the DB can be an expensive operation.
Are you worried about closing the connection object out from under another caller? If so, as another response pointed out, I think you are safe with the code you provided.
I don't think so.
Since c is a local variable ("stack variable") and not a static one every call has it's own instance of c.
Next you create a new object (the connection) and return this.
Shouldn't be any problem with concurrency, because each call is a new connection.
I might make one change, though: make the method private.
This will force you to put all your data access code in one class and push to create a nice, separate data access layer. At very least make it internal so that your data access layer is confined to a single assembly (that's separate from the rest of your code).