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 7 years ago.
Improve this question
AT the moment, the site I look over sends an activation email to new members which have a link they must click to activate their account. While this seems like a good idea, it has many faults such as occasionally the email lands in their spam/junk folder and its yet another step the user has to do.
I was try to make it easier for users to join and activation seems to be the biggest hurdle. We have put this in place to avoid spammers and scammers and it does work. I don't want to go for the 'moderation' method either.
Any suggestions?
One alternative is to do it the the way StackOverflow does and create an account by linking it to their gmail account (or similar) automatically. Theres minimal hassle to the user then and its a valid way of attempting to ensure that the user is legitimate
I think at this point, email activations and CAPTCHAs are so common, the users are used to it. I wouldn't worry about email activations, but I would warn against overuse of CAPTCHA. I'm thinking of one forum I checked out recently which insisted on an image and logic CAPTCHA on registration, and then again for each of your first five posts. Considering the image CAPTCHA was the same generation each time and the logic CAPTCHA was identical each time, I think it was overkill.
I'm guessing that by the "'moderation' method" you mean actually have moderators that watch over the site and ban spammers. I can understand your dislike for such a system, but an alternative that a lot of sites use is peer moderation (e.g. StackOVerflow or Slashdot). This still means that spam gets posted, but it usually gets flagged or otherwise modded down so far that no one will ever see it.
Another tactic is a reputation system that requires a certain level of rep before one is allowed to post links. StackOverflow has a system like this as well (you can't even comment before you reach a certain level of reputation). This can be a little annoying at the beginning, but it's definitely effective at eliminating spam.
And as already mentioned by others, CAPTCHAs are probably the easiest anti-spam technique to implement. There are many libraries and APIs out there for generating CAPTCHAs, and you can even put the tests to good use by using reCAPTCHAs to help digitize books. The drawback is that automated CAPTCHA-deciphering algorithms are getting better and better, and the spammers without the ability to implement them can often farm the work of solving CAPTCHAs out to 2nd/3rd world workers.
Whatever method you choose, there's going to be some level of inconvenience for the user, but most of the common techniques are readily accepted by users and worth the trade-off to eliminate spam.
The most used way is a verification mail + captcha, because usually emails from unknown sources aren't sent to spam folder. I tried this way with Gmail and Hotmail and both are working perfectly.
You can also use other systems such as using the OpenID (I think this is a very good way), Gmail account, Facebook acccount etc...
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 months ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm working on an application that is meant to distribute emails by the thousands. We've started interfacing with Mandrill to accomplish this.
So my coworker suggests that we use a subdomain to send all of theses emails out, so as to protect our top-level domain's reputation. We started squabbling about this because, as I argued, why would a simple subdomain protect our TLD, especially if they both resolve to the same IP address? If marketing.example.com is sending thousands of emails, aren't spam filters smart enough to know that they really originate from example.com?
So to clarify:
We're currently using Mandrill to distribute mail
We use DKIM to verify that the domain example.com is the originator of the message
Right now, we're only using one server to handle all this (plus Mandrill)
So how would switching the sender to marketing.example.com (with matching DKIM) help protect our TLD's reputation as a non-spammer? I don't understand, yet I've read articles to this effect, and he argues fervently that it's the right thing to do, yet no one can tell me how it works. I understand it from an organizational standpoint, but I don't understand how that protects our domain, unless spam filters really judge rep by the subdomain.
Can someone please help me piece this together?
Edit:
Here are some articles for reference:
Quora Question
LuxSci Blog
Mail Chimp Delivery - See page 11
Using a sub-domain will mitigate against the potential damage that could be done to your reputation by a miscreant user sending a campaign to a purchased list and using sub domains is considered best practice as per what you have read online.
In the first instance the big mailbox providers are not expecting to treat all mail sent from a domain in the same way. Google will want to classify your marketing messsages differently to notifications/transactional mail. One way to assist the mailbox providers in that task is to utilise sub-domains for different message types.
It is not about attempting to evade the spam filters, it is about providing meaningful and useful information through what most would consider proper utilization of rDNS. You are only mitigating because even if the BL operator or mailbox provider do assign separate reputations to each subdomain if sub-domains are being listed constantly then you do run the very real risk of having your TLD listed.
Spamhaus who operate one of the most widely used blacklists said this on the subject "It's a good way to convey in rDNS what is really happening within your network in terms of different customers sending different mailstreams. The risk is that "maindomain.com" may get filtered if too many subdomains look bad, but that needs to be a risk you accept and manage by maintaining the reputation of all subdomains."
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 5 years ago.
Improve this question
I am working on a project that has very complex integration needs, specifically with receiving and sending EDI data and all the "fun" stuff that happens in between. I can definitely focus efforts around data processing (validation, required fields, transformation), but the problem I am having is how to frame stories and epics in the backlog to plan and track work.
It is very easy to say "As a manager, I can deny a vacation request so that I can make sure that I have enough workers on staff to meet my commitments." Actually, I am very very good at this, but I am very new to this kind of integration effort.
For a big integration project, it is tougher to indicate who the user is, and what the value is. The EDI integration are just interface (non-functional) requirements, but the implementation is a big effort.
Can anyone provide some guidance on how to structure / frame these kinds of requirements in the product backlog I am creating?
Mike Cohn has something to say about this, I think this last paragraph is very relevant
But, you should be careful not to get obsessed with that template. It’s a thinking tool only. Trying to put a constraint into this template is a good exercise as it helps make sure you understand who wants what and why. If you end up with a confusingly worded statement, drop the template. If you can’t find a way to word the constraint, just write the constraint in whatever way feels natural
Scrum does not specify that requirements should be written as user stories and you should use what ever technique best works for you. If you are battling with "AS A" type stories, try "IN ORDER TO AS A I WANT ". If that does not use, use use case modeling.
Requriments are not contracts, but placeholders for communication. The key here is to have just enough information for planning purposes giving the team a sense of knowing what has to be done. The details can be discussed in sprint.
What I do in situations like this is:
1) Try and come up with the simplest bit of end-to-end functionality that we can implement for the integration.
2) Try and come up with a use case for that integration
3) Translate that into stories (optional step: Stories aren't a law of physics. You use 'em if they're useful.)
For example:
1) Okay - looks like authentication is the most trivial thing to implement that touches everything.
2) Hey - authentication by itself is useful. We can use it to know whether this group of users can access the data.
3) "As a site administrator I want to make sure that only authorised stuff have access to Foo to prevent valuable information being publicly accessible"
This way you'll always have a working EDI system - it just cover a subset of the functionality. A subset you can grow over time - hopefully in order of the importance of the functionality to your business.
My real preference however would be to dig a bit further in to why the EDI is being done. Generally it won't be because "EDI" is a feature that people want. It'll be because the EDI is necessary for some other bit of functionality in the system.
In which case, rather than having a separate EDI project, I would much rather use whatever the thing-that-needs-EDI is to drive the development of the EDI layer. The stories in (3) above will then be coming from a live project - and you'll be much more likely to build what you need and avoid waste.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have already built a site from scratch. It has banning, PM, comments, etc. The PMs and comments are done using markdown (like SO).
There are pros and cons for writing my own or using another software. But some cons keeping me from using another forum software is
Multiple Logins: One for the site, one for separate forums.
Need to Customization code: I'll need to change the toolbar in the forum software so I can access pages on the regular site.
Look consistency: It may look drastically different from my site even after applying lots of css changes.
Banning and User consistency. Users may be ban on site or on forums but not the other. users may select a different or multiple usernames on the forum instead of being forced to use the same username on both site and forum.
Should I write my own forum code or should I use something already written? What are some reasons for or against writing my own and using forum software?
The heuristic I tend to use is that if at least two or three of these are true, it's probably worth writing yourself:
It's one of your core business offerings.
You have the time, money and resource to specify, design, build, test and support it.
The amount of time you would need to spend evaluating, prototyping with, integrating and customising off-the-shelf packages is near to or greater than the amount of time you estimate that it would take you to build your own.
The off-the-shelf packages do not have good support. By 'good support' I mean that you can raise an issue, and be assured that somebody will look into your specific issue and provide a fix if it is found to be a bug.
None of the off-the-shelf packages meet your quality bar for security, performance, quality, etc.
You are not writing open-source software, and the off-the-shelf packages have a viral open-source license; be particularly wary of AGPL and other similar licenses.
One of the oft-quoted articles about this is from Joel Spolsky. Lately he seems to have just been writing flame-bait, but this was one of his worthwhile early posts.
Note that you can also take a combination approach, and use some pre-built things such as recaptcha and gravatar even from within a bespoke solution.
Writing your own forum software is nowadays in almost no case useful. The available software is highly customizable. For example, you can create your own skin to fit with the layout of your website. You can integrate the login with that of your website.
Writing your own forum is so complicated that the quality of your own software will be much lower than of something like phpBB or vBulletin. And dont forget the security bugs, the mentioned software has been reviewed by a huge amount of people. Until you reach the same quality (functionality, stability, security, etc), your website will be outdated and your forum software with it.
Once again, the current forum software is so adaptable and extensible, that it doesnt make sense to make your own.
I think it highly depends on your needs for the forum.
First off, is the forum itself an essential part of your website's function? Or is it more of a 'support' style forum?
If it's essential to your daily business, then it makes more sense to write your own - or at least highly customize an existing package.
If what you need instead, however, is a vehicle for customer support, or some sort of generic community revolving around your site, I might recommend looking at a completely different vehicle: something like http://getsatisfaction.com, or a Google Group, or some such.
(I'm in no way affiliated with either of those sites).
Regardless of the solution you choose, I'd recommend you give some serious thought to how essential the forum is. If it's not, then I wouldn't waste too much time configuring/setting one up. Instead, focus on what your site's main draw is, and spend the bulk of your time on improving that. You and your userbase will be much happier with that, IMO.
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
Most of the websites I've used in the past (including this one) do not offer an option to delete your own account.
I think the main reason is to avoid the orphanage of the items created (or the delete on cascade of those items).
Modern sites (like this one) have a place where those items go when an account is abandoned (in the case of SO it is the user "Community").
What is, in your opinion, the rationale of not providing a "delete my account" feature?
Security? Laziness? Ignorance? Bug? Or feature?
We are designing a small web app, and we are discussing precisely this topic. We can't find too many reasons though for not allowing the user to delete the account.
This is a pretty broad topic, but some of the ones I've experienced are:
Accounts can be tied to comments, deleting the account screws up the comments
Accounts can tied to other systems (community server, authorize.net and blackbox web services) and can be hard to delete on those
Cascade, like you mentioned
Prevent user stupidity - accidental delete is hard to undo, and even trickier on a subscription site
Return on investment - try explaining to your boss why you're doing a weeks worth of data integrity testing instead of setting a boolean to false
Marketing - "We have 85,000 registered users" (see: myspace)
Will it be more work to maintain those abandoned accounts than you would normally have? Also, are people that visit your site likely to come back to it after long periods of time? These are questions your team might want to discuss.
Personally, unless it is going to cause a disruption or slowdown in work, I would keep the accounts. That way, users won't complain when they visit six months down the road and find they cannot log in.
This may not apply to you. But in our system, we deal with patient data. Because of privacy, security and regulatory concerns, we do not delete users. We have extensive audit trails indicating who accessed/entered/changed which pieces of information. We provide a mechanism to disable access, but the audit trails must remain in tact, so the health care facilities can monitor and enforce their privacy policies.
I'm pretty sure I've quoted this Udi Dahan article but it's worth posting again here.
The key point is to model the task, not the data. Do you truly want to nullify the existence of a user (he/she never existed)?
I'd say either lack of foresight or "not worth the effort" judgement.
As a user, I want to be able to contact a company and request that my account be wiped.
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 10 years ago.
Improve this question
When trying to link some well established tools to my company's active directory, I hit a roadblock. I was told that:
"Sorry, I cannot trust our domain admin password to [F/OSS] software...".
This question deals specifically with how to convince IT that F/OSS software isn't (automatically) less trustworthy than any other software just because it's free/oss.
I'm doing fine with adopting OSS software (I'm a linux ninja at heart) so to put it another way: How can I promote the acceptance of OSS at my company?
The technical issue of tying into AD without an admin account is for another post.
EDIT:
I got some clarification on these issues. This really has little to do with the active directory and all to do with trust of F/OSS in general. So I think my original bolded questions are still valid, just ignore the part about the "admin password".
Any IT person worth their salt will be well aware of the benefits of open source software.
The answer that has been given sounds to me like a palm off answer, some possibilities of why they don't want to implement it could be:
Possible lack of enterprise level support for that specific software open source software
Not wanting non-IT department employees to be modifying the active directory (you)
The software you have found doesn't have the industry recognition that other similar products have
There is no perceived benefit for the IT department for the work it would require them to do (both in the initial setup and ongoing maintenance)
I work as a sysadmin. From my perspective this question isn't about trusting Open Source software specifically. Your IT person mentioned a specific case saying he didn't trust it with the domain admin username and password. I think he may be concerned with the software storing that username and password. If that is in fact how it works I would deny the request for open source or commercial software. No properly setup system should need to store the domain admin username and password, possibly an account with lower credentials, or depending on the tool if it is interactive have it setup to ask for credentials at runtime and authentcate against the domain.
Bottom line you need to work with IT to come to a better understanding of your and their needs. Things need not always be only a yes or no issue.
I would try it this way:
Why would open-source software be less trustworthy than it's close-sourced equivalent? If anything, the transparency of its code would require that it be even more trustworthy, in terms of private data storage such as passwords, since any attempt to subvert it would be discoverable by examining the source code.
This, of course, is only valid if the company compiles the source themselves, and does not trust a binary distribution.
Ask them if they have read the license since that is what they object too. Ask them specifically what in the license is an issue for them. If what they are really resisting is Open Source Software, then that is a separate issue from resisting the GPL.
Why not run as a non domain admin? I can understand why they don't want to give a domain admin password to any software. Especially if there is only one "Domain Admin" account.
How about you determine exactly the permissions needed to run the software and request a new account with only those permissions. You could convice them to put this in a different OU, with additional auditing. If the software provides value, you are creating a process for them to "audit" and decide to trust OSS.
Identify exactly what he cannot trust about F/OSS software and then you can tailor your explanation to address his concerns.
Is it concern about backdoors being coded in?
Is it concern about code quality that leads to security risks?
Is it concern about how soon security risks will be fixed?
"how to convince IT that F/OSS software isn't (automatically) less trustworthy than any other software just because it's free/oss."
"How can I promote the acceptance of OSS at my company?"
You can't.
All you can do is the following.
Find the F/OSS they currently use. This can be hard. In some cases, it's trivial because many folks use Apache and Java without thinking about it.
Ask how is what you're going to use different than what they're already using?
That will make the case for exactly one new piece of F/OSS. Or, they'll go crazy and banish stuff they've been using.
You can't make a general understanding happen. You can only make the case one specific detailed case at a time until someone else starts to piece the big picture together on their own.
Sometimes they are not, sometimes they are. You need evidence to backup your thoughts.
CVE numbers don't lie. Go to http://cve.mitre.org/ , http://www.securityfocus.com/bid/, http://www.secunia.com and compare commercial and OSS version of the same line of products that you'd choose.
See which one is better sometimes it's the fact that the OSS product is really rubbish such as PHPNuke but sometimes it's darn good when it comes to security such as qmail.
Also don't forget you need to choose a OSS solution which got a good community otherwise you might see the project is dead after a year. this is possible in the commercial world, but let's face it less likely
I would put the onus on IT to prove their case. Simply ask "why not?", or possibly "what evidence do you have that this is any less secure than non-GPL software?". If they attempt to give some explanation, you can take some of the other suggestions to explain their misconceptions to them. If they just stubbornly stand their ground, they are standing in the way of you doing your job - and for no good reason. Gently explain to them how you have found incredible value (ie free) software that adds value to the company, and that you're sure the higher levels of management would want you to take advantage of it. Hopefully this will remind them they have no evidence. If even this fails and it's important, you could then take it to higher levels of management, but proceed with caution as it's a sure fire way to make enemies.
What tools do you want to use? Make the business case about how much time/$$ will be saved by using these tools. Give examples of other, highly-successful companies (Google comes to mind) that use these tools.
First and most importantly, make sure these decisions by IT are being recorded somewhere. Email or whatever. If you can't do your job effectively because of them, make sure you have enough documentation to redirect the blame where it belongs.
Look beyond IT. Your sysadmin may be following rules set down somewhere else in the company, typically a legal department. If that's the case, you may have a company lawyer who doesn't know about software or FOSS reacting with a corporate lawyer's typical reaction to the unknown - forbid it. After you've demonstrated cost and security benefits, you may need to ask the company to reach out to a legal expert in the area of FOSS.
You're talking about Windows admins. Just point out how MSFT has handled recent security issues (like the recent IE holes that have mainstream media telling people to use alternate browsers) and ask how OSS can be any worse.