I want to store browser's network information into database. How can I do this in ruby on rails?
Network information like - All individual request that comes in network that I want to store into database.
Is there any gems or any api that I can get this information and store into database?
Thanks
Related
I am currently creating an iOS application with Swift. For the database I use Firebase Realtime Database where I store among other things information about the user and requests that the user sends me.
It is very important for my application that the data in the database is not corrupted.
For this I have disabled data persistence so that I don't have to store the requests locally on the device. But I was wondering if it was possible for the user to directly modify the values of the variables during the execution of my application and still send erroneous requests.
For example the user has a number of coins, can he access the memory of the application, modify the number of coins, return to the application and send an erroneous request without having to modify it himself.
If this is the case then is it really more secure to disable data persistence or is this a misconception?
Also, does disabling access to jailbroken devices solve my problems? Because I've heard that a normal user can still modify the request backups before they are sent.
To summarize I would like to understand if what I think is correct? Is it really useful to prevent requests to save locally or then anyway a malicious user will be able to modify the values of variables directly during the execution and this without jailbreak?
I would also like to find a solution so that the data in my database is reliable.
Thank you for your attention :)
PS : I also set the security rules of the db so that only a logged in user can write and read only in his area.
You should treat the server-side data as the only source of truth, and consider all data coming from the client to be suspect.
To protect your server-side data, you should implement Firebase's server-side security rules. With these you can validate data structures and ensure all read/writes are authorized.
Disabling client-side persistence, or write queues as in your previous question, is not all that useful and not necessary once you follow the two rules above.
As an added layer of security you can enable Firebase's new App Check, which works with a so-called attestation provider on your device (DeviceCheck on iOS) to detect tampering, and allows you to then only allow requests from uncorrupted devices.
By combining App Check and Security Rules you get both broad protection from abuse, and fine-grained control over the data structure and who can access what data.
I'm saving data that keeps track of a users virtual purchases inside the Documents directory of the app's sandbox. For obvious reasons I don't want the user to have access to this file or be able to manipulate it.
Is this the proper directory for storing these files? If not where can I store files that can not be accessed by the user?
I did find this link from Apple that suggests that data such as this should be stored in the Library directory. It doesn't seem to say if it's secure from users accessing it though.
I'm not an iOS security expert, however, I can share my experience of working with users data on iOS. Any corrections/remarks are appreciated.
Generally speaking, the best recommendation would be to store important user's data remotely (i.e. having a server backend or using iCloud) with SSL-protected connection. However, if you are forced to store data locally for some reason, here are some recommendations:
1) Do not ever save important data in Documents directory or in NSUserDefaults as is. It's pretty easily accessible for user even on non-jailbroken devices. For instance, you can check iExplorer: as far as I remember, it does the trick.
2) If you really need to store some data locally, whatever your choice is: Documents folder, UserDefaults or CoreData, you have to encrypt it. Algorithm choice is up to you, but it's better to use some iOS built-in solution for it.
3) The data encryption assumes having a key for your app to decrypt it. The best way to store your key is KeyChain. Probably, that is the only place where you can store keys and other stuff like user's authorization data with no worries of being stolen from the outside.
Eventually, after all these steps your user's encrypted data can still be accessible by user. One won't be able to read it unless it is encrypted, but having access to the own keychain and some skill, an advanced user can finally get the original data. Moreover, it still can be damaged. So, in terms of saving data from being damaged or removed you still need to store backups or the data itself somewhere remotely.
You should treat data in the Documents directory as public. Anyone with an iOS device hooked up to a computer via USB using a tool such as iExplorer or iFunBox can view the contents of your application's Documents and Caches directory. For safety, consider using the keychain (if applicable), or a web service which validates the receipt (shared secret, user information, etc) to make sure that the user actually purchased the product, and isn't trying to spoof a transaction.
Let's say I have some data that I obtained through a non-graphql endpoint for example from third party server (firebase).
How do I put the data into the local relay store?
Is there an easy way to add / edit / overwrite data to relay store directly without going through query or mutation?
A non public RelayStoreData field is accessible from the Relay.Store instance and it gives you direct access to the records contained in the store. I haven't done anything with this myself but you could try modifying the cache directly like this:
RelayStore._storeData._cachedStore._records[recordId][fieldName]=newValue
I would use relay without a server, defining your graphql schema locally and doing your API requests from your graphql schema the same way you would query a database in your schema.
https://github.com/relay-tools/relay-local-schema
JMeter's Access Log Sampler requires common log format logs to replay http requests. I want to use it to replay actions in a Rails application from the log, including params passing. Is there any way to do this with JMeter or any other tool? I suppose I could parse the logs into curl requests, but can this way maintain session information (keeping track of which user performed which action)?
Edit I should say what this is for. It can be useful for either performance testing or data recovery. In our case we need to verify some data in the database by using our logs because the db may have data integrity issues.
I am looking at paper_trail to get this kind of functionality in the future. For the app in question, we had to do some heavy-duty log parsing to get the results we needed. It included separating the actions out by IP address (thus similating sessions, although some IP addresses contained multiple user sessions) and parsing the actions and params in the logs. It was not 100% effective at reproducing the exact state of the database, but it was pretty close.
HTTP Raw Request for JMeter may help with this
I'm developing a blackberry application to remotely access an external customer database.
Selected employees can change customer entries via a webinterface accessible in our intranet.
I don't want the blackberry to contact the database on every request, so I built in a local storage, which stores the top 50 selected customers of the blackberry user.
What the best practice to keep both records in sync? I thought about creating an hashcode of each record to reduce the datasize to transfer (and though the energy necessary to transmit it). Can anyone here tell me what they do, to reduce requests by a mobile device?
Thanks,
rAyt
In a couple of different situations I've added a created/modified timestamp to each record. On a successful sync with the server, you note the last server time, store it on the client, and on the next sync only get the records (if any) that have changed since the last one. This will reduce data but you may still have to deal with records that were changed on both client and server since the last sync.