"The best practice for what permissions to ask for is that you should only ask for the permissions you need right no."
Is this a typo? I believe "no" should be "now".
https://developers.facebook.com/docs/getting-started/graphapi/
Yes, I think it's a typo.
You don't have to, but it's a good practice to ask permissions just before you need them:
"Never ask for permissions you think you might need in the future. People will be suspicious and may reject your app."
You can find more explanation about that here:
http://developers.facebook.com/docs/facebook-login/permissions/
Related
People have been saying that JForum is easily customizable, and lots of other things in favor of JForum. Through this question, I want to know from those who have used both Jforum and phpbb, that how easy or difficult is customization of the forum in both of these.
For example, say you want to change the theme/template. In my experience I found it much easier to change theme in phpbb ( but still haven't found a way to change the theme in JForum).
Please also suggest some resources where I can find some support for JForum, I couldn't find any support/documentation and so I'm still confused whether to switch to phpbb even if the client prefers Java?
To put this question another way, is there any reason why someone should use JForum when phpBB is available? (I hope it's not the same thing as Java vs Php)
Ok, 1 month and no answer! Looks like this question is not much important, perhaps because there aren't many who have used JForum and phpbb both.
After going through both of them, I eventually decided to go with phpbb given the customization possible, so my vote is towards phpbb. Opinions on this question are still welcome.
Django does not deletes old file when new one is uploading. Instead of it adds '_' to the a new file name and keep old file in the storage. How it can be solved?
It appears that your question is not your real question.
First, your title is just a complaint. You might want to fix that.
Second, "How it can be solved?" is a terrible question, since it isn't a "problem" that needs a "solution". It's a feature of the field.
Third, in a comment (not the question) you ask this ("So there is no way to delete the file? "), which is perhaps worse than both other questions.
The answer is "no". It's not true that there's no way to delete the file.
(Hint, avoid negative questions.)
My preference is to leave it at that. The answer is "No". Please ask better questions.
But, I'll provide a hint as to what I'm guessing your real question is.
http://docs.djangoproject.com/en/1.2/ref/models/fields/#django.db.models.FieldFile.delete
I will agree with the comments that this is a feature and not a bug but I will point out that there was a ticket opened (and later closed as wontfix) against Django that might be helpful if you would like to try to "fix" this. See http://code.djangoproject.com/ticket/11663 for a patch and additional comments/guidance.
I have heard of people being able to access other sites cookies using XSS. Is this is a legitimate option and how do you achieve this?
It's not a legitimate option, and will probably get you flagged as malware.
If you're trying to do something useful (i.e. non-evil), there's probably a legitimate way of doing it.
It's definitely not a legitimate option. It's considered a security hole anywhere it exists, and if you rely on it in your application, it will fail when those holes are fixed.
I would like to know your opinion on whether it is a good idea to have developers put their name or signature on top of every test they write and why (not)?
I would say no. If you really need to know who wrote the test, you should be able to look back in your version control to see who's to blame. When people start putting their name on things, you lose the sense of collective ownership/blame, and people start to get more concerned with "their" code rather than the system as a whole.
I upvoted Andy's but I'd also add that putting the name in the code also is then something else that must be maintained. eg. Joe creates the test, but Jane changes it, is it Joe's test or Jane's test? And if Jane doesn't change the comment, you'll now go and talk to Joe about the code that Jane wrote... All too confusing. Use Blame and be done with it.
What would you do with the information?
There's no use case for having the author's name.
Generally, the information has one of two meanings.
The person's gone (gone from the company, gone from the project, or a contractor and someone who'll never be found again.)
The person's still around.
In the second case, you already knew that. Having their name in a source code file doesn't clarify the fact that they worked on this code, are still with the company and still on the project.
So, author's name has no use cases.
I favour self-explanatory test cases rather than signed tests.
Even if you know who wrote the test, and he's still working here, and he's available, you cannot be certain he remembers the reasons why he wrote this test.
Make sure the names of the test case are explicit enough. Add comments if necessary, reference bug ID, User Story, Customer ...
I think it depends on the attitude that already exists. If there are many conflicts, then removing all the names is useful, because the code stands for itself. However, if the names are put on the tests (as with code) then the developer is taking ownership.
Taking ownership is always a good thing because it encourages the developer to make it as perfect as possible. It also helps when you need to ask a question about the test, or if the test is failing, and you can't figure out why, you'll be able to ask the expert on the subject.
However, if there is a darker atmosphere, more about developers who are defensive, and are trying to undermine each other, then the names will cause them to focus on 'who made this code wrong' or 'this test failed because X coded it badly' rather than focusing on the error that the test might be detecting.
So there's always a balance when explicitly attaching names to tests like that.
And as Andy mentioned, there's always source control if you REALLY need to know who wrote something.
I think it really depends on what the rest of your culture is around code ownership. If your teams culture is that all code is owned by someone, and only that person can touch that code, then labeling whose code is whose might make sense.
However, I prefer to work on teams where there's collective ownership of code. Sometimes it's nice to have an original author on a file, just to see whose original design it was, but beyond that, I don't think tagging specific tests is useful.
As other people mentioned, if you really need to figure out who made a particular change, you can figure that out from version control. In general though, I think tests should be owned and maintained by the whole team.
We have a lot of open discussions with potential clients, and they ask frequently about our level of technical expertise, including the scope of work for our current projects. The first thing I do in order to gauge the level of expertise on staff they have now or have previously used is to check for security vulnerabilities like XSS and SQL injection. I have yet to find a potential client who is vulnerable, but I started to wonder, would they actually think this investigation was helpful, or would they think, "um, these guys will trash our site if we don't do business with them." Non-technical folks get scared pretty easily by this stuff, so I'm wondering is this a show of good faith, or a poor business practice?
I would say that surprising people by suddenly penetration-testing their software may bother people if simply for the fact that they didn't know ahead of time. I would say if you're going to do this (and I believe it's a good thing to do), inform your clients ahead of time that you're going to do this. If they seem a little distraught by this, tell them the benefits of checking for human error from the attacker's point of view in a controlled environment. After all, even the most securely minded make mistakes: the Debian PRNG vulnerability is a good example of this.
I think this is a fairly subjective decision and different prospects would react differently if you told them.
I think an idea might be to let them know after they have given business to someone else.
At least this way, the ex-prospect will not think that you are trying to pressure them into giving you the business.
I think the problem with this would be, that it would be quite hard to do checks on XSS without messing up their site. Also, things like SQL injection could be quite dangerous. If you stuck with appending selects, you might not have too much of a problem, but then the question is, how do you know it's even executing the injected SQL?
From the way you described it, it seems like a poor business practice that could be a beneficial one with some modification.
First off, any vulnerability assessment or penetration test you conduct on a customer should be agreed upon in writing by that customer, period. This covers your actions legally. Without a written agreement, if you inadvertently cause damage (application crash, denial-of-service, data leak, etc) during your inspection, you are liable and could be charged (under US law; other countries have different standards).
Even if you do not cause damage, a clueless or potentially malicious customer could take you to court claiming damages; a clueless judge might just award them.
If you have written authorization to do so, then a free vulnerability assessment to attract potential customers sounds like a show of good faith and demonstrates what you want -- your skills.