Account (adress) not found on Nanopool - mining

I decided to try mining ZCash on a Nanopool pool. I don't understand why an account is still not being created. Mining on nheqminer CPU produces better than GPU. The problem is that I still don't see my account with a balance.
Remember: to add your account to the database you should find at least one share
One share was found (unfortunately I can't provide a screenshot), but nothing has changed on the wallet page.
How to understand when a share will be found and whether a wallet will be created

Related

Considerations for Creating Industrial Applications (Native/Web)

What considerations are needed when creating a web app that is intended to be used in an industrial plant setting for a company? My specific use case is an industrial facility with several different production plants that would each have its own device for the application interface.
How do companies enforce the usage of such apps on a monitor/tablet? For example, could I prevent them from using other stuff on the tablet?
Importantly, how would security work? They'd share a device. There may be multiple operators that use the app in a given shift. Would they all use the same authentication session (this is not preferable, as I'd like to uniquely identify the active user)? Obviously I could use standard username/passwords with token based sessions that expire, however, this leaves a lot of potential for account hijacking. Ideally, they'd be able to log on very quickly (PIN, perhaps?) and their session would end when they are done.
As long as there is internet connection, I would presume that there isn't much pro/con regarding the use of native applications versus web based or progressive web apps. Is this assumption correct?
What's the best way of identifying which device the application is being run on?
Is this a common thing to do in general? What other technologies are used to create software that obtains input from industrial operators?
--
Update - this is a good higher level consideration of the question at hand, however, it has become apparent why focused, specific questions are helpful. As such, I will follow up with questions that are specific.
Identifying the Area/Device a Web Application is Accessed On
Enforcing Specific Application Use on Tablets
Best Practices for Web App Authentication in Industrial Settings
I'm not able to answer everything in great detail but here are a few pointers. In the environment as you describe we usually see these two options. 1) you tell them what you need, internet, security, if they give you device and how it will be configured 2) they tell you exactly what you need to deliver.
I do not think you can 100% prevent them. We did it by providing the tablet( well laptops in our case) and the OS configuration took care of that, downside we had few devices to support. You seem to hint that there is always an internet connection so I guess you can collect all info about the system and send it back to you daily?
We were allowed to "tap" into their attendance SW and when you entered the facility you were able to use your 4 digit pin to log in if you were out of premisses you could not log in at all. I can imagine the following: you log in with your username and password - this does full verification, after that, you can use 4 digit pin to login for next n hours.
maybe, kinda, depends on what you are doing. Does the browser have all features you need? Our system needs multicast to perform really fast, so we have a native app
touched on this in 1. You could also use device enrolment process. You can also contractually force them that there will be only your software and it may invalidate support contract. It really depends on your creativity. My favourite( and it works - just tell them, there will only be installed my software and if not you will pay me double for support. I only saw one customer who installed some crap on the device when there were told not to
it really depends on what industry you are talking about, every industry is different. We almost always build a custom solution
The enforcement of the device/app usage depends on the customer, if the customer asked for help in the enforcement, then you can provide guide, training and workshops. If the customer serious about the enforcement then it will be a policy that's adapted by all the organization from top to down. Usually seniors will resist a workflow change more than juniors, so top management/executive should deal with that. Real life story: SAP team took 6 months to transform major newspaper workflow, during that few seniors got fired because they refuse to adapt the change.
Security shouldn't handicap the users, usually in industrial environment the network is isolated or at least restricted through VPN to connect multiple sites (plants in your case), regarding the active user: we usually provide guide/training/workshop for the users and inform them that using colleague account or device will prevent the system from tracking your accomplishment/tasks, so each user is responsible to make sure the active account/device is the one assigned to him/her.
It depends, with native you have more controls than web, but if the app is just doing monitoring then most of today apps use web for monitoring and the common way to receive input is REST APIs (even if the industrial devices doesn't support REST API, a middleware could be written to transform the output). If you need more depth about native vs web you need to ask new question with more details about the requirements.
Depends on the tech you are using (native or web), and things I mentioned in point 2: you can use whitelist of devices that's allowed to run the app. overall there are many best ways to track down the device.
How common in general? I think such information can only be achieved by survey, the world full of variations. And having something common not mean its safe or best, our industry keep changing at all levels. So to stay in the loop, we must keep learning and self-updating without reboot.

Get Paypal Sandbox to remain signed in for longer than 5 minutes

I am sick of the absolute pile of rubbish that is the paypal sandbox for numerous reasons but one thing that is annoying me especially at the moment is the login cookie length. It lasts all of 5 minutes before you have to log in again. You lose the page you were on and end up back at the dashboard after punching in your password for the 500th time that day.
I am testing reference transactions (another completely embarassing sandbox implementation) and whenever I go to check or change something in the account I am using to pay I am logged out.
Is there any way to force it to keep me logged in for longer?
if you are logging into another account to pay, this is why you are being logged out. try using another browser, or private browsing to keep your logins separate.
I work with the sandbox every day and I don't have any issues in general. Not sure why you would be talking so badly about it.
The session thing is something PayPal does (like any financial website) to protect people. Yes, it's the sandbox, but it's meant to simulate the live PayPal site, so that session will act the same.
As for your comments about reference transactions, I guess you'll need to expand on that. I've thoroughly tested reference transactions in the sandbox for numerous projects and have never had any issues with it.
One thing I could recommend that would help with typing in the password over and over (as well as help you maintain good password standard practices in general) is to use LastPass. You'll never have to type a password again.
Another option would be to setup a local solution using the TransactionSearch and GetTransactionDetails APIs. For example, I've started something like that with my PayPal Glass project, which is essentially replicating the PayPal interface with my PHP class library. Notice that I don't have any sign in protection on that at all, so it never times out or anything.
It's a little more effort up front, but you can save lots of time in the future with projects like you're working on. If you're working with PHP you could grab that PayPal Glass project from GitHub and just use it with your own sandbox.

Don’t get any measuring data from iHealth cloud (sandbox)

I write an application that uses the api of iHealth. Scales, blood pressure monitor, and devices like that by iHealth send there data with Bluetooth and smartphone apps to the internet cloud of iHealth. Therefore a user of this devices has a user account in the iHealth internet cloud. There he can login and see his data. My app uses the iHealth api to get the data from this cloud. The user of the devices gives mi the right to access his data by OAuth 2 and after receiving the access data I ask for the data of the user with the given client id.
Well, here comes the problem. As a result I get a JSON-Object of measuring data without any data. That means there is no error message, everything seems fine, except that there are no data of this user. It's no kind of error documented here:
sandbox.ihealthlabs.com/dev_documentation_ResponseFormatAndErrors.htm
Http status is good too (200).
I don't use any optional restrictions like asking for data of only certain time.
An explication would be that the user still hasn't used his devices and the cloud therefore doesn't has any data. Unfortunately this is something I can't influence: My app is still not ready and therefore I only use the sandbox cloud offered for development (http://sandbox.ihealthlabs.com).
The sandboxuser can't use the smartphone apps and therefore I can only read the data that are yet there in the cloud. Of course I can't test without data. Who could develop without reciving data? There has to be an error. Maybe a rather silly error. I asked more than 9 days ago the support but still haven't got any answer.
Getting JSON data from the cloud with the api for blood pressure (openApiBP) (the XX-parts are abbreviated id, token, ...):
http://sandboxapi.ihealthlabs.com/openapiv2/user/d7XX..XX9f/bp.json/?client_id=a6XX..XXbe&client_secret=2bXX..XX3f&redirect_uri=http%3A%2F2Flocalhost%3A8082%2FTelemedicina%2Fdispositivos.html%3Fregreso%3DiHealth&access_token=u8XX..XXyw&sv=6cXX..XXcf&sc=deXX..XXcf
The answer to this (w/o any change) is just:
{"BPDataList":[],
"BPUnit":0,
"CurrentRecordCount":0,
"NextPageUrl":"",
"PageLength":50,
"PageNumber":1,
"PrevPageUrl":"",
"RecordCount":0}
Using the Api for Weight (OpenApiWeight) has the same problem as the OpenApiBP.
I have read the documentation more than once and searched for an explanation in the web.
As you see I ask the api and get this maybe correct but useless answer for development purposes. Any idea? What do I miss?
Update:
An iHealth Lab tecnican answered me. In the sandbox is just now user data. My way of asking and the recifed answer are therefore correct. It's not an error. To get data the application has to be registered for the real world. He didn't explain how to test with this limitation of the sandbox.
I let the the answer of the iHealth Lab api technician speak for itself:
"The sandbox does not provide any actual user data. If you want actual live data you will have to register a new application at developer.ihealthlabs.com."
If this is the answer to my question of why not reciving any data means there is really no data that I could recive.
Thanks to all that tried to help me, especially Scott Lawson. I hope this answer will help others. Knowing this a few days ago would have saved me a lot of time.

Protect from bots creating multiple free accounts and uploading files

I am developing a web for my university where users can create an account and upload images. Images are private and can only be seen by the person who uploaded them. For instance, is like a cloud file system.
Each user have a free account with 500MB. I am using Amazon S3 to store the images, that is to say storage implies costs.
How can I avoid that bots upload millions of MB? How can I avoid that a bot creates million of new accounts and upload 500MB per account without affecting the user experience?
On one hand I definitely don't want to put a CAPTCHA in the registration form because it negatively affects the conversion rate. On the other, I don't want to pay thousands of dollars because a bot upload million of dummy images.
Does anyone know whether Dropbox, Google Drive, etc, suffers from this (content uploaded by bots)? It seems that is not a problem because I couldn't find anything about it. All spam related problems I could read about only covered spam in forums. It makes sense also. Spam in forums can be read by other users. Spam in a service like Dropbox or Google Drive reaches no one. Nonetheless I have to protect it to avoid cost surprises.
As far as I can see, without using CAPTCHAs this can be done:
Set up monitoring systems that warn for specific abuse patterns (the same IP uploading lots of data and creating new accounts repeatedly).
Throttle users that follow those patterns; this will hopefully make them realize and make the process worthless. If this fails, then disable those accounts and have their owners mail/talk to you in order to explain what's happening.
Since you say it's a system for your university, make users provide proof of enrollment (e.g. an university e-mail address) in case of abuse.
Have this forbidden usage explicit in your terms of use.
Of course, a smart enough bot can work around all those problems.
For a more advanced solution, you might try some machine learning or AI that learns about normal and abnormal usage patterns, then applies that information to judge a possible abuser.
I would recommend to :
make users register using their email
don't allow multiple accounts for a single email
send them an email registration confirm, and deactivate the "unconfirmed" accounts after a short amount of time (eg 3 days)
AFAIK, Drupal embeds this kind of controls out-of-the-box or with little effort (and no programming).
This won't solve all your problems, but in fact it will reduce the risk of bot exploits.
As you said you need a registration, there are two points to tackle this problem - make sure no bots register and/or limit the number of uploads.
I personally would use both points. For the user signup, design a login form where the user has to enter its email address, send them a mail with a link in it and activate their account only after clicking this link. Or let the user solve a simple math question on signup.
For the second point, you can store the number of uploaded bytes per user and time. You can then set a quota on allowed upload usage per time, for example you may not upload more than 10MB per hour. If a user hits this limit more than n times, you can deactivate his account.
And: set up and alerting and monitoring system. For example monitor the number of non-activated users, monitor the amount of uploads etc. and set up alerts if these exceed a certain threshold.
The above mentioned methods may not be perfect and probably won't block out all bots, but they will at least make it way harder for bots to upload unwanted data. Also these methods are quite simple, so you can start of with your project and see if this is really a problem. And if you get bots to upload data, you will at least receive alerts and can invent a better solution afterwards.

Avoid running of software after copying to next machine?

I have developed a small software. I want to provide and run it commercially only. I want it to be run in the machines who have purchased it from me.
If someone copies it from my clients computer and runs it in next computer, I would like to stop functioning/running the software.
What can be the ways to prevent the piracy of my software?
Adaption of one of my previous answers:
There are a few ways to "activate" copied software to try to stop casual copying of the application.
In the most simplistic case, a registration code ("CD key") purchased from you, possibly via your website, and it is sent to the user who enters it into the program or installer. The whole process can basically be done offline; the program itself locally determines that the code is valid or invalid.
This is nice and easy, but it extremely vulnerable to key sharing - since there's no "phoning home" then the application cannot know that thousands of different people are all using the same key that they got off the internet or a serial library or their friend. It's also reasonably easy to make "keygens" which generate valid-seeming keys that were never actually issued by the developers.
Then we get into online registration. You still have some kind of code, but the program will phone home back to the server to determine whether the code is valid and usually unique. This stops basic key sharing, because the company knows if too many people from all over the world are all using the same key. Perhaps there is some kind of identification involved using MAC address, too, with infinite registrations allowed on the same hardware but maybe a limited number on what appears to be a different computer.
This is still pretty easy and stops simple key sharing. People will actually have to get into cracking the software or faking the server response to get past it.
Sometimes the program itself is partially/mostly encrypted and is only decrypted by the online registration step. Depending on how well this is obfuscated then it can be pretty difficult and time consuming to crack. Bioshock was a high-profile example of this - debuting with a brand new encryption/copy protection scheme that took around two weeks from release to be broken.
Finally, a particularly guarded application might stay in constant contact with the server, refusing to work at all if the connection is severed.
If you know for sure that all your users will all have reliable internet connections then it can be considered quite a strong way to protect the app, at the cost of privacy and some user distrust of the spyware.
In this case to get around the activation they would need to fake the server itself. Steam emulators and private WoW servers are an example of this.
And in the end, nothing is uncrackable.
In a nutshell: you can't.
Even very sofisticated systems (e.g. dongle keys) can be circumvented.
I guess your best call is to give a code to your customers and have an online check for that code, so that it cannot be used twice.
Of course, that can be circumvented too but...
As nico said you really can't.
A simple solution might be to generate (registration/activation) codes that are based on hardware or software installed on the particular computer - eg video card serial id or c:/windows creation time.
I have one idea may be it works.
What we can do, we will make an encorrupted database field and that field will be empty for the first time as soon as i install my software to some machine it will read the Mac Address + Mother Board Serial + Processor ID and make an encorrupted value with the combination of these three and write in to that field which i left empty for the first time use.
After that every time my application will read these three values and recreate the encrupptted value in the same manner and compare with the value of that database field. If the value of the database field and the value of the regenerated encrroupted field is equal, that means the computer is same other wise it is installed on some other machine in this case you delete all the code and can make the system unstable to punish the person also :) ...
Please let me know about your opinion about this idea.
The best way is to use some sort of hardware-locking in which your license code contains encrypted info about the machine on which it will run. Your software will then check for this info and match it with the current computer and if the match is successful, the license is deemed valid.
Sure, any scheme can be cracked by someone on the face of the planet, but that does not mean you shouldn't use a protection scheme.
If you are looking for a ready-made scheme for this, have a look at CryptoLicensing.
Companies such as ours (Wibu-Systems), Safe-Net, and Flexera (expensive) offer dongle-free solutions as well as ones based on hardware. But _simon was right in that a dongle is the only iron-clad protection. All software-based systems can be cracked; it's just that some are more difficult than others. Really good hardware-based solutions are effectively uncrackable. No one has yet cracked the CodeMeter stick unless the implementation was flawed.