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 like how facebook releases features incrementally and not all at once to their entire user base. I get that this can be replicated with a bunch if statements smattered all throughout your code, but there needs to be a better way to do this. Perhaps that really is all they are doing, but that seems rather inelegant. Does anyone know if there is an industry standard for an architecture than can incrementally release features to portions of a user base?
On that same note, I have a feeling that all of their employees see an entirely different completely beta view of the site. So it seems that they are able to deem certain portions of their website as beta and others as production and have some sort of access control list to guide what people see? That seems like it would be slow.
Thanks!
Facebook has a lot of servers so they can apply new features only on some of them. Also they have some servers where they test new features before commiting to the production.
A more elegant solution is, if statements and feature flags using systems like gargoyle (in python).
Using a system like this you could do something like:
if feature_flag.is_active(MY_FEATURE_NAME, request, user, other_key_objects):
# do some stuff
In a web interface you would be able to isolate describe users, requests, or any other key object your system has and deliver your feature to them. In fact, via requests you could do things like direct X% of traffic to the new feature, and thus do things like A/B test and gather analytics.
An approach to this is to have a tiered architecture where the authentication tier hands-off to the product tier.
A user enters the product URL and that is resolved to direct them to a cluster of authentication servers. These servers handle authentication and then hand off the session to a cluster of product servers.
Using this approach you can:
Separate out your product servers in to 'zones' that run different versions of your application
Run logic on your authentication servers that decides which zone to route the session to
As an example, you could have Zone A running the latest production code and Zone B running beta code. At the point of login the authentication server sends every user with a user name starting with a-m to Zone A and n-z to Zone B. That way roughly half the users are running on the beta product.
Depending on the information you have available at the point of login you could even do something more sophisticated than this. For example you could target a particular user demographic (e.g. age ranges, gender, location, etc).
Related
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 8 years ago.
Improve this question
We're creating a new web app based in Node. As many apps do, we would like to restrict the number of users who sign up, so we can test and scale up smoothly. So, people would sign up (with an email address), and then when a batch of users are released (either manually or automatically), that batch would receive an email that would allow them to sign up.
I've seen this process a number of times on the user side, but have never been involved with building a beta queue system, so I'm not sure the best way to approach this from a architecture / code perspective. Some specific questions might be:
What would be the flow for signup from a Node perspective?
What might be the underlying data model?
For "time-released" or batch releases of users, what might be the best way to manage that or trigger it?
Are there are node modules that might help with this?
Any help appreciated.
I implemented something like this in a .Net / SQL Server setup.
Basically, the user table had a flag indicating that that user was a beta user and allowed access.
Then I modified the user authentication module to return a different error message indicating that the were signed up but they couldn't access the application yet. This would only show if they successfully authenticated like normal. You could also send them to a different landing page so it doesn't look like they used the wrong credentials.
Next you can provide an admin interface to kick off a script to set the beta flag on a batch of users. This should also trigger some type of notification to let the user know they have access.
For time released options, you could have something else trigger the batch script to set the flags, or have a monitor service that finds any users without access that signed up over X days ago.
I think a lot of this would need to be customized based on your application and when you want to release beta users. There are also some services out there that allow single sign-on and gather analytics about your beta users if you want to see more information without having to roll your own.
Hope this helps. It would be nice to see an actual module you could drop in and configure with your specific database, user model, and authentication / signup process.
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 3 years ago.
Improve this question
Social networking is great, but there is something fundamentally wrong with the way social networking is implemented today in most popular services. I'll put it in this example: Imagine that there is no SMTP, and consequently, it is globally assumed and accepted that you can only send email to addresses on the same domain. The result would be the emergence of a single email service, let's call it emailbook.com, which we all have to subscribe to, if we really want to communicate with the world.
This is what's happening with social networking today. You HAVE to use the same service your fiends/colleagues are using to talk to them.
I would like to be able to put up my own social site, invite my friends who trust me, share amongst us, but still be able to share with the world at large.
What are the chances of this scenario happening in the future? What does it take?
There sure is, and not just one! The future you wanted is now here.
By the time of the question, back in the end of 2010, OStatus had already existed for half a year, and the year before that there was OpenMicroBlogging (OMB), and at about the same time as OMB, the XMPP XEP 0277.
Since then several other protocols have popped up, such as diaspora* just half a year later, and later some smaller players like Friendica's DFRN and HubZilla's Zot.
OStatus never left draft status, but the big buzz[0] these days is about ActivityPub, which is a W3C recommendation since January 2018 and came out of the Social WG mentioned by #keithjgrant in his answer. There is a multitude of implementations[1], finding their niches with different use cases like microblogging, blogging, link sharing, picture sharing, video sharing and audio sharing.
There is also the collection of blog-oriented protocols described on https://indieweb.org/.
[0] pun intended
[1] Diaspora and GNU Social, although shown at fediverse.party, do not implement ActivityPub. The other applications shown do. There are several other applications not shown there, such as FunkWhale, Plume, WriteFreely, Prismo ... There is no terse and complete overview of all of them, but several are listed at https://switching.social/ and https://wedistribute.org/ publishes news and interviews related to all of them.
There are a few. One Social Web uses XMPP which is open and decentralized like SMTP.
Check it out.
http://onesocialweb.org/
I absolutely agree. The good news is, yes, things are happening. Even better, they are happening in the W3C, which means open standards.
The W3C now has a Social Web working group. They are actively working on a handful of standards. The biggest of these seems to be the Social Web Protocol.
Today, they also posted the W3C Recommended spec for Webmention, which is sort of an improved version of the old pingbacks that used to be used on blogs, this time built on HTTP. It allows a post to notify another page on the web when it references it. There are already a number of libraries and services that implement this today.
I think you should take a look at http://code.google.com/apis/opensocial/. It is a spec developed by google and other social networking players. It supports interoperability and much more.
OpenSocial is currently being developed by a broad set of members of the web community. The ultimate goal is for any social website to be able to implement the API and host 3rd party social applications. There are many websites that support OpenSocial, including hi5, LinkedIn, MySpace, Netlog, Ning, orkut, and Yahoo!
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 8 years ago.
Improve this question
Let's say I have designed s very important system, and this system costs thousands dollars. I want to protect my system with a serial number as I know crackers will try to edit the binary code to bypass the serial number.
I have read about using a checksum function and apply it over my binary code and check the value if changed, but again, we are talking about a condition a cracker can avoid by editing the code.
My question is: what's the most used technique to protect important programs?
I have yet to see a "protected" digital product that had not been cracked pretty quickly after its publication (or in some cases, before its publication). Sorry, but it's the reality. You have to get the revenue by making a good product. Most of those who want to use it and can afford, will pay.
There will be a few dickheads, but that's life. You better be kind towards the legit users of your software and not bully them with weird copy protection attempts that don't work anyway.
If your app is working offline, whatever checks you do (check sums, serial code validity, etc), do them often, repeating verification code, in many routines of your software. Obfuscate your code, to make reverse engineering a more difficult task, and, if you have the possibility, implement an online check, part of the core functionality of your app residing on your server, and being serviced only to those installations that you have checked server-side for valid license key. Associate the license key to some form of unique identifier of the hardware the app is running on, and if you check online, have statistics concerning the IPs that make the verification request: if you encounter more IPs trying to verify the same license key, contact the buyer and approve a list of IPs they usually log on from, whilst blacklisting any other until specific request from them, either by mail or by phone.
The most used technique is serial numbers. But your customers will have access to the code, so they will be able to bypass your serial number check, no matter how much work you put into obfuscating it.
However, if you can provide your software as a subscription-based or one-time-payment web application, then people will not be able to do this. Whether this is feasible or not depends on the type of application you're writing.
I would always recommend to build a custom software protection before applying any kind of commercial protector such as a Packer.
In any case just a serial validation and a checksum check are not going to keep crackers away.
I would recommend you to visit my new blog www.anti-reversing.com and take a quick look at the anti-piracy tips & tricks page just to have an idea about what I am talking about.
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 9 years ago.
Improve this question
What's the best way to close the loop and have a desktop app "call home" with customer feedback? Right now our code will login to our SMTP server and send me some email.
The site GetSatisfaction has been an increasingly popular way to get customer feedback.
http://getsatisfaction.com/
GetSatisfaction is a community based site that builds a community around your application. Users can post questions, comments, and feedback about and application and get answers to their questions either from other members or from members of the development team themselves.
They also have an API so you can incorporate GetSatifaction into your app, and/or your site.
I've been playing with it for a couple of weeks and it is pretty cool. Kind of like stackoverflow, but for customer feedback.
Feedback from users and programmers simply is one of the most important points of development in my opinion. The whole web2.0 - beta - concept more or less is build around this concept and therefore there should be absolutely no pain involved whatsoever for the user. What does it have to do with your question? I think quite a bit. If you provide a feedback option, make it visible in your application, but don't annoy the user (like MS sometimes does with there feedback thingy on there website above all elements!!). Place it somewhere directly! visible, but discreet. What about a separate menu entry? Some leftover space in the statusbar? Put it there so it is accessible all the time. Why? People really liking your product or who are REALLY annoyed about something will probably find your feedback option in any case, but you will miss the small things. Imagine a user unsure about the value of his input "should I really write him?". This one will probably will not make the afford in searching and in the end these small things make a really outstanding product, don't they? OK, the user found your feedback form, but how should it look and what's next? Keep it simple and don't ask him dozens questions and provoke him with check- and radioboxes. Give him two input fields, one for a title and one for a long description. Not more and not less. Maybe a small text shortly giving him some info what might be useful (OS, program version etc., maybe his email), but leave all this up to him. How to get the message to you and how to show the user that his input counts? In most cases this is simple. Like levand suggested use http and post the comment on a private area on your site and provide a link to his input. After revisiting his input, make it public and accessible for all (if possible). There he can see your response and that you really care etc.. Why not use the mail approach? What about a firewall preventing him to access your site? Duo to spam in quite some modern routers these ports are by default closed and you certainly will not get any response from workers in bigger companies, however port 80 or 443 is often open... (maybe you should check, if the current browser have a proxy installed and use this one..). Although I haven't used GetSatisfaction yet, I somewhat disagree with Nick Hadded, because you don't want third parties to have access to possible private and confidential data. Additionally you want "one face to the customer" and don't want to open up your customers base to someone else. There is SOO much more to tell, but I don't want to get banned for tattling .. haha! THX for caring about the user! :)
You might be interested in UseResponse, open-source (yet not free) hosted customer feedback / idea gathering solution that will be released in December, 2001.
It should run on majority of PHP hosting environments (including shared ones) and according to it's authors it's absorbed only the best features of it's competitors (mentioned in other answers) while will have little-to-none flaws of these.
You could also have the application send a POST http request directly to a URL on your server.
What my friend we are forgetting here is that, does having a mere form on your website enough to convince the users how much effort a Company puts in to act on that precious feedback.
A users' note to a company is a true image about the product or service that they offer. In Web 2.0 culture, people feel proud of being part of continuous development strategy always preached by almost all companies nowadays.
A community engagement platform is the need of the hour & an entry point on ur website that gains enuf traction from visitors to start talking what they feel will leave no stone unturned in getting those precious feedback. Thats where products like GetSatisfaction, UserRules or Zendesk comes in.
A company's active community that involves unimagined ideas, unresolved issues and ofcourse testimonials conveys the better development strategy of the product or service they offer.
Personally, I would also POST the information. However, I would send it to a PHP script that would then insert it into a mySQL database. This way, your data can be pre-sorted and pre-categorized for analysis later. It also gives you the potential to track multiple entries by single users.
There's quite a few options. This site makes the following suggestions
http://www.suggestionbox.com/
http://www.kampyle.com/
http://getsatisfaction.com/
http://www.feedbackify.com/
http://uservoice.com/
http://userecho.com/
http://www.opinionlab.com/content/
http://ideascale.com/
http://sparkbin.net/
http://www.gri.pe/
http://www.dialogcentral.com/
http://websitechat.net/en/
http://www.anymeeting.com/
http://www.facebook.com/
I would recommend just using pre built systems. Saves you the hassle.
Get an Insight is good: http://getaninsight.com/
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
Regarding Agile development, what are the best practices for testing security per release?
If it is a monthly release, are there shops doing pen-tests every month?
What's your application domain? It depends.
Since you used the word "Agile", I'm guessing it's a web app. I have a nice easy answer for you.
Go buy a copy of Burp Suite (it's the #1 Google result for "burp" --- a sure endorsement!); it'll cost you 99EU, or ~$180USD, or $98 Obama Dollars if you wait until November.
Burp works as a web proxy. You browse through your web app using Firefox or IE or whatever, and it collects all the hits you generate. These hits get fed to a feature called "Intruder", which is a web fuzzer. Intruder will figure out all the parameters you provide to each one of your query handlers. It will then try crazy values for each parameter, including SQL, filesystem, and HTML metacharacters. On a typical complex form post, this is going to generate about 1500 hits, which you'll look through to identify scary --- or, more importantly in an Agile context, new --- error responses.
Fuzzing every query handler in your web app at each release iteration is the #1 thing you can do to improve application security without instituting a formal "SDLC" and adding headcount. Beyond that, review your code for the major web app security hot spots:
Use only parameterized prepared SQL statements; don't ever simply concatenate strings and feed them to your database handle.
Filter all inputs to a white list of known good characters (alnum, basic punctuation), and, more importantly, output filter data from your query results to "neutralize" HTML metacharacters to HTML entities (quot, lt, gt, etc).
Use long random hard-to-guess identifiers anywhere you're currently using simple integer row IDs in query parameters, and make sure user X can't see user Y's data just by guessing those identifiers.
Test every query handler in your application to ensure that they function only when a valid, logged-on session cookie is presented.
Turn on the XSRF protection in your web stack, which will generate hidden form token parameters on all your rendered forms, to prevent attackers from creating malicious links that will submit forms for unsuspecting users.
Use bcrypt --- and nothing else --- to store hashed passwords.
I'm no expert on Agile development, but I would imagine that integrating some basic automated pen-test software into your build cycle would be a good start. I have seen several software packages out there that will do basic testing and are well suited for automation.
I'm not a security expert, but I think the most important fact you should be aware of, before testing security, is what you are trying to protect. Only if you know what you are trying to protect, you can do a proper analysis of your security measures and only then you can start testing those implemented measures.
Very abstract, I know. However, I think it should be the first step of every security audit.
Unit testing, Defense Programming and lots of logs
Unit testing
Make sure you unit test as early as possible (e.g. the password should be encrypted before sending, the SSL tunnel is working, etc). This would prevent your programmers from accidentally making the program insecure.
Defense Programming
I personally call this the Paranoid Programming but Wikipedia is never wrong (sarcasm). Basically, you add tests to your functions that checks all the inputs:
is the user's cookies valid?
is he still currently logged in?
are the function's parameters protected against SQL injection? (even though you know that the input are generated by your own functions, you will test anyway)
Logging
Log everything like crazy. Its easier to remove logs then to add them. A user have logged in? Log it. A user found a 404? Log it. The admin edited/deleted a post? Log it. Someone was able to access a restricted page? Log it.
Don't be surprised if your log file reaches 15+ Mb during your development phase. During beta, you can decide which logs to remove. If you want, you can add a flag to decide when a certain event is logged.