Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
How can I protect my REST API to identify fake request generated by some user / script and flooding my server with millions of requests?
If some one wrote any script or program and generate millions of calls to my REST API how can I protect my service from these request so that my API wont goes down. One way is I can use captcha but captcha is useful when caller is human. If caller is an application I can not use captcha. Is there any frameworks available for the same to handle such scenarios?
What your service is experiencing is called a DoS / DDoS attack. This is currently one of the most common attacks on web services.
There are many ways to mitigate such attack all
boiling down to separating the legit requests made by your API consumers from the malicious ones performed by the attacker/attackers. Such attacks are usually automatized and therefore the requests resemble one another in some way (IP range, HTTP headers, etc.). For example a very simple approach would be to identify the IP range that the attack comes from and block it out on your service's firewall.
There are a few posts here that discuss prevention of (D)DoS, e.g. How do major sites prevent DDoS? or What techniques do advanced firewalls use to protect againt DoS/DDoS?.
Third party services/products might help you protect your API. I don't want to mention any here as I don't want to advertise any of them. You'll need to do some searching.
Good luck.
You can pass a token for each request.
This token should be use any encryption algorithm and use a secret key to encrypt and decrypt token in both client and REST service.
Ex :
Client request : What is the weather of Chennai ? Token : chennai + 123 (Key)
Server Response : chennai123 : its valid : response 40 !!
Here key is 123 it should not available in public
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a REST API which receives some information (let's say events) from clients. Now I need to send some information from the server to clients. I'm trying to add MQTT as an additional way for clients to communicate with the server. Unlike HTTP MQTT allows me to do both: sending and receiving, so it's possible to make MQTT analogs for all existing REST API methods.
Receive events from clients - HTTP, MQTT
Sent commands to clients - MQTT
My idea was to make a "listener" which subscribes to all "event" MQTT topics and translate them into HTTP requests to the REST API (to keep components decoupled). But there is a problem: this listener is a simple client. It doesn't have any special permissions and can't get publisher's credentials to act on his behalf when talking with the REST API. MQTT doesn't even allow a subscriber to get who published a particular message.
One solution is to use MQTT only for sending information from the server to clients and keep using REST API for all incoming requests. But that looks strange :)
Another way is to use broker custom hooks but not all brokers support it and it's not a part of the MQTT specification so it's not very reliable.
Any ideas how to organize it in a proper way?
Given that most (if not all) MQTT brokers support wildcard topics in ACLs you can encode the user in the topic and then grant the agent access to the wild card topic that matches all users.
e.g.
publish to events/<user>
and then grant the agent access to the topic events/+
You can then make sure that the Users ACL makes sure only they can publish to events/<user> such ensuring that users can not impersonate each other.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
We are looking for a data logger to connect to a PLC through Modbus TCP or RTU. I have found several of these on the market, but I need the ability to post the data back to a web server. Basically we have a website that uses a graph to show the current values from the PLC over time and this data shouldn’t be more than a few seconds old. We have used a raspberry pi, but we are looking for alternatives for a more industrial environment.
Critical features
1. If the connection is lost, then the data that has been logged since the last connection should be sent up.
2. A backup of the logged data should be stored on the device
3. Use some type of frequent update mechanism to send data to the server like a html post.
I have only found one device and I wonder if Im using the wrong search terms/lingo or if COT devices do not exist with these features.
I did a similar project recently using a B&R Plc, and the AsHTTP library. It was able to do http put / get requests directly to a resource on the Web. (I've seen the term rest API used in the Web world) You could write your own code to buffer and store the data locally on flash memory in case it disconnects from the net.
Also B&R lets you use ModbusTCP for free directly through the ethernet port.
I've never used a "data logger" standalone device, but this is one option.
Investigate using an Omron NJ Series PLC with SQL Connection capabilities. This PLC could grab any data on another PLC through EtherNet/IP. From there, it has the ability to log to an SQL Server.
A very useful feature that I have made extensive use of is the spool function. If the connection between the NJ and the SQL Database is broken, the NJ will retain the data that wasn't logged in its own memory and insert it automatically once the connection is reestablished.
https://industrial.omron.ca/en/products/nj5-database-connection
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
My server needs to send emails on the behalf of my client, and the client wants this email to at least appear to originate from them.
The easy way is to just spoof the From address. The hard way is to get the client's username and password, and actually send from that account.
My questions are:
Will spoofed email trigger spam filters? (In my test, Apple Mail did not think it was spam.)
Is this considered a bad practice, or unethical, or in any way frowned upon?
The emails are going out only to people who have specifically and explicitly requested the email, and it will likely be a small number of people (less than one per day). We are not sending out spam at all.
Because this is an important client, I don't want to do anything that would reflect negatively on them (or myself).
Thanks. Hope this isn't too subjective.
Email spoofing is not completely preventable, since the basic protocols from email exchange don't verify anything.
This might help you decide:
http://en.wikipedia.org/wiki/Email_spoofing
Which says historically:
In the early Internet, "legitimately spoofed" email was common. For example, a visiting user might use the local organization's SMTP server to send email from the user's foreign address. Since most servers were configured as "open relays", this was a common practice. As spam email became an annoying problem, these sorts of "legitimate" uses fell out of favor.
I would think it is acceptable as long as the message is spoofed to a return address you would like people to respond to.
However, it would be more standard and appropriate to use email/pass.
I suppose it depends on how difficult this would be in your situation, but if reasonably able, don't spoof.
You said:
The emails are going out only to people who have specifically and explicitly requested the email, and it will likely be a small number of people (less than one per day).
If the email contents have perhaps a small footnote, I don't think it would be terrible. I have seen similar things from many companies. It's your decision.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I would like to write some integration tests which verify if user receive registration confirmation e-mails.
Ideally, for this purpose I would like:
Create temporary e-mail account.
Pass it in registration form.
Check if we receive e-mail.
Delete e-mail account.
Are there any disposable e-mail accounts which provides a simple API? I couldn't find any, but existing ones are fairly easy to parse/make requests (e.g. http://10minutemail.com/).
Is this sounds like a good idea? The alternative is use some gmail account and use tags for this purpose. However, dealing with msgs in spam folder, other folders, etc. sounds a bit more complicated.
you can test with your email from Gmail, just append +something to your email address:
myemail#gmail.com
you can have a test account that will deliver to your normal Gmail address:
myemail+testuser1#gmail.com
myemail+testusern#gmail.com
http://mailinator.com supports POP3.
Connect to the server via POP3 with any username and check e-mail.
I know this question is relatively old, but this fits your purposes quite well:
https://www.guerrillamail.com
Disposable email addresses
Emails are deleted after 60 minutes
Customizable temporary email address dashboard
I use it on the daily while testing emails or for signing up for services that I'll only use once, that require email verification.
I highly recommend it!
You may use special services for QA/QC engineers with API:
https://mailtrap.io
http://www.emailvoid.com
https://mailcatcher.me
https://mailsac.com
More you can read in article http://railsware.com/blog/2012/06/18/remove-qa-headache-while-testing-email-delivery/
If you're running on a linux machine it'll already have an email service running (username#localhost... eg root#localhost) which is kinda perfect for testing emailing scripts.
I don't know why you'd go to the trouble of automating this when it would be better to rather use dependency injection and create a mock-mailing class so you can adequately do integration testing - instead of the last stage of transmitting the email it simply writes the content to a file, a database, or just stays alive in the mock-object long enough it can be tested before it's garbage collected.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Here's a simple idea, based on some reading.
Server stores a hashed version of (plaintext + salt). This avoids passwords being seen, as long as the hash is hard to reverse.
When client attempts login, server sends it (salt,random), ie a constant salt and a newly generated random string.
Client sends back hash(hash(plaintext + salt) + random), ie client appends the salt, hashes, then appends the random, then hashes again.
Server checks that the hashed value is the same as it's own H(H(pwd+salt)+rnd).
I don't have much experience with this, so can I ask what the potential issues are? Also, what does one normally do with the salt? Can you really get away with using the same salt?
The scheme you are suggesting doesn't add any security to checking a password and simply adds complexity that using SSL for login doesn't. With SSL you can safely just transfer the plaintext password from the browser to the server, hash it with the salt, and then check against the stored hash. This eliminates the need for complex schemes. At this time, only nationstates can actually feasibly break SSL connections in a systemic way, although some really enterprising hackers have found some interesting vulnerabilities.
The scheme you are describing sounds very much like a Diffie-Hellman zero knowledge key exchange, which is much more secure than ssl as it never actually transfers the password after it is initially set up with the server. The problem with this kind of key exchange today, is that it must be written in Javascript on the client side and, as such, exposes the actual workings to every attacker that cares to look. The attacker could then just replace your Javascript with something else, or just tap into it to collect the initial passwords if you don't use SSL, so you are again just down to the security of the SSL connection from client to server with only a bunch of added complexity and failure points. There are ways to use ActiveX, Java, or other items to create browser plugins to handle all the key exchange stuff, but this again, adds a failure point for users that will be non-obvious, adds an extra step for the user that other sites don't require (installing the add-on or bookmarklet), and keeps you in development a lot longer for no real benefit.
Firefox has been working on implementing a Diffie-Hellman key exchange for passwords at the browser level, and this, if it ever takes off, will allow a lot of added security and make this kind of password scheme feasible.