Find content
Male
We actually have very good sources of revenue that provides free access to everyone. Free is key to us. Something, as essential as an app, should be free to everyone. I don't want to have to use a white label version. I want to minimize the amount of administering to keep our community active while I focus primarily on content. I've been relying on Invison to keep up their end of it to provide robust solutions. In my humble opinion, this solution adds a barrier and it just doesn't make sense to me.
Please don't tell me again that if I don't want to use or pay for the app, then don't. I have no problem personally paying for an app. I appreciate the effort it takes to design and develop applications. I am speaking for my visitors and members whom I don't believe should have to pay for direct access to my forums via an app.
Just like "video killed the radio star" so has the App (and tablet) killed the web and browser as we know it. I suggested in the other thread that I'm sure many of you have followed about Forums and Invision being toast in 5 years, that it isn't because of Facebook, rather it's because of the App that our forums will be dead in 5 years. I believe a robust, freely accessible App (not just a mobile skin) is essential and we should ALL be pushing it on our forum members and visitors as quickly as possible in order to keep our forums competitive and active.
#2263577 App now available
Posted
on 05 May 2012 - 05:38 PM
#2263543 App now available
Posted
on 05 May 2012 - 04:54 PM
wmarcy, on 05 May 2012 - 03:38 PM, said:
I have 25,000 users. How about you?
Jeffrey Roberts, on 05 May 2012 - 03:45 PM, said:
I have 50,000 users on one forum and 5,000 on another and despite everything that I've read here, I still think charging a fee for this app is not good business.
If you have that many users, then this app would be a great thing for you, you can purchase the white label option (when available), sell it for 1.99 or even give it away for free with some ads on it.. this will lead to a nice little income source for your site. If you are not interested in that and just want it free, then you can do that as well after purchasing the white label service.
On one of my sites, we took donations to purchase an app, paid for it, and gave it to those users that donated for free, after that, we are selling it for 1.99, it's been a nice little monthly income for us and has paid for itself each and every month with the sales. I haven't had one user complain that it should be free at all, everything has a cost to it and they don't mind chipping in at all.
#2263219 App now available
Posted
on 04 May 2012 - 09:55 PM
I had been waiting for a long while for this app. Now, I am quite disappointed that there is a cost associated with it.
I believe Invision should just suck up the cost for development and support given that we are all paying semi-annual fees for each of our IP.Boards. It's the cost of doing business for Invison in this new app world. Personally, it feels like a money grab. Also, since we are bringing all of our users to the App store to buy this app, I'm further disturbed that Invison planned no revenue share for us. It's a hell of a lot more than just $1.99. If 10,000 of my members buy this app that's $19,900 to Invision --- a heck of a lot more than I've ever paid to Invison.
I worked for an operating system software vendor back in the 80's and 90's. Our biggest mistake was that we charged a fee for our development environment. That fee became a huge barrier for any developers to create applications that ran on our OS. I believe Invision just made the same mistake charging a fee for something that is so basic.
If you want to play in the big leagues you need to get your app out there. Plain and simple. I urge Invision to take another look at this.
I believe Invision should just suck up the cost for development and support given that we are all paying semi-annual fees for each of our IP.Boards. It's the cost of doing business for Invison in this new app world. Personally, it feels like a money grab. Also, since we are bringing all of our users to the App store to buy this app, I'm further disturbed that Invison planned no revenue share for us. It's a hell of a lot more than just $1.99. If 10,000 of my members buy this app that's $19,900 to Invision --- a heck of a lot more than I've ever paid to Invison.
I worked for an operating system software vendor back in the 80's and 90's. Our biggest mistake was that we charged a fee for our development environment. That fee became a huge barrier for any developers to create applications that ran on our OS. I believe Invision just made the same mistake charging a fee for something that is so basic.
If you want to play in the big leagues you need to get your app out there. Plain and simple. I urge Invision to take another look at this.
#2247238 A proposal toward improving IP.Board security
Posted
on 28 March 2012 - 02:28 PM
When it comes to password security on a forum you're really talking about 3 possible scenarios:
To prevent people randomly trying to guess passwords on the login form, after x attempts, start presenting a captcha on the login form to slow them down a bit more. Lets be honest, no-one is going to keep this up for long. I would put money on all of these types of manual "attacks" are just a user annoyed at being banned / warned and trying to guess an admins password to get back at them. Either way, they'll likely get bored fairly quickly and give up.
Whatever happens, don't lock the account. That's just punishing the real member for someone else trying to hack them.
For scenario 3, once an attacker has a copy of your database, there isn't really a whole lot you can do. The best option here is to use a slow crypt method like bcrype, or PBKDF2. These are specifically designed to make brute forcing a password a slow, long and painful experience.
When it comes to password / member security, it's important to remember the context. Does a forum need password security on the same level as an online banking website for example? The benefit vs hassle for the member needs to be considered.
With that in mind, I'd like to address your proposed list:
I'd have no problem increasing the option default to 7 characters, but it must be an option. If I run a closed community with 3 members on a LAN and I want them all to have the same single character password of 'a', then that is my choice as the admin. The software should give me that choice, but also provide me with a warning / information that lets me make the right choice when I'm fiddling with the ACP settings.
Agreed. As the password is hashed, so takes up a known amount of space in the users table, there is no reason to have an upper limit on the password.
Agreed, see above.
I believe this to be unnecessary. It would involve a lot of developer time from IPS to implement (different SMS gateways for different countries, keeping them all up to date, constant testing, and so on) and a lot of work for the admin to setup, not to mention a possible large bill for the uninformed admin who doesn't read the SMS gateway pricing fully before signing up. All this for a service that few sites would use, and even less users would use. Who wants the hassle of waiting for a slow SMS to arrive being being able to login? That's a forum I would never use. I think that IPS developers time could be better spent here.
This option would be handy on the very rare occasion that a sites entire database gets stolen but how would it work? Would all passwords become blank, forcing the user to choose a new one when they logged in? If so, what is to stop anyone from randomly setting new passwords for any user? If the user is forced to enter their existing password first, then there is nothing to stop the attacker doing the same, as they have your database and have likely brute forced half your MD5 passwords by now. If a system like this where to be implemented, it would need to be done carefully (admins don't read warnings), and it would need some thought as to why the system is needed, and what could be done to prevent such a system being needed.
I'm all for this, if I as an admin want to force my users to have upper case, numbers, and all manner of junk in their passwords, then I should be able to. Again though, this boils down to the cost vs benefits need to be weighed up. Will enough admins make use of it to warrant IPS developing it or is it an option that is better suited to an add-on?
What's the use-case for this one? I'm not sure why you would want to do this.
I'm all for logging every single admin action, IP.Nexus-style, but again, this is just a forum and database sizes need to be considered. How large would the admin_logs table be for a large site with 5 admins that has been running for 6 years? Also, these logs exist elsewhere. Apache for example logs every request and it is unlikely that these could be easily deleted by someone who has gained access to your ACP. Is duplicating this information in your ACP really needed?
Making the admin logs impossible to delete would also be tricky. Removing options from the ACP is fine but stopping them from just dropping the admin_logs table, or selectively deleting rows is a different matter.
At this stage, I think that the only option is to restore your site from a pre-hack backup rather than trying to see what the hacker has done and trying to undo their changes.
So to summarize: Slow down remote brute force attempts and use a slow crypt method, those are the options that get my vote
- Someone is trying to brute force a members password by just trying random passwords in the login form.
- Someone is trying to automate a brute force attack on the login form
- Someone has stolen your database and is brute forcing your members passwords offline.
To prevent people randomly trying to guess passwords on the login form, after x attempts, start presenting a captcha on the login form to slow them down a bit more. Lets be honest, no-one is going to keep this up for long. I would put money on all of these types of manual "attacks" are just a user annoyed at being banned / warned and trying to guess an admins password to get back at them. Either way, they'll likely get bored fairly quickly and give up.
Whatever happens, don't lock the account. That's just punishing the real member for someone else trying to hack them.
For scenario 3, once an attacker has a copy of your database, there isn't really a whole lot you can do. The best option here is to use a slow crypt method like bcrype, or PBKDF2. These are specifically designed to make brute forcing a password a slow, long and painful experience.
When it comes to password / member security, it's important to remember the context. Does a forum need password security on the same level as an online banking website for example? The benefit vs hassle for the member needs to be considered.
With that in mind, I'd like to address your proposed list:
Ryan H., on 28 March 2012 - 08:46 AM, said:
- Increasing minimum password length to 7 characters, or making it configurable.
I'd have no problem increasing the option default to 7 characters, but it must be an option. If I run a closed community with 3 members on a LAN and I want them all to have the same single character password of 'a', then that is my choice as the admin. The software should give me that choice, but also provide me with a warning / information that lets me make the right choice when I'm fiddling with the ACP settings.
Ryan H., on 28 March 2012 - 08:46 AM, said:
- Removing the upper bound on password length, or increasing it beyond all practicality. (1)
Agreed. As the password is hashed, so takes up a known amount of space in the users table, there is no reason to have an upper limit on the password.
Ryan H., on 28 March 2012 - 08:46 AM, said:
- Converting to or providing the option of a time-expensive cipher for password hashing, such as Blowfish/bcrypt. (2)
Agreed, see above.
Ryan H., on 28 March 2012 - 08:46 AM, said:
- Implementing an optional two-step authentication process via SMS. (3)
I believe this to be unnecessary. It would involve a lot of developer time from IPS to implement (different SMS gateways for different countries, keeping them all up to date, constant testing, and so on) and a lot of work for the admin to setup, not to mention a possible large bill for the uninformed admin who doesn't read the SMS gateway pricing fully before signing up. All this for a service that few sites would use, and even less users would use. Who wants the hassle of waiting for a slow SMS to arrive being being able to login? That's a forum I would never use. I think that IPS developers time could be better spent here.
Ryan H., on 28 March 2012 - 08:46 AM, said:
- Providing a means of invalidating all system passwords and sessions, on a global or per-group basis. (4)
This option would be handy on the very rare occasion that a sites entire database gets stolen but how would it work? Would all passwords become blank, forcing the user to choose a new one when they logged in? If so, what is to stop anyone from randomly setting new passwords for any user? If the user is forced to enter their existing password first, then there is nothing to stop the attacker doing the same, as they have your database and have likely brute forced half your MD5 passwords by now. If a system like this where to be implemented, it would need to be done carefully (admins don't read warnings), and it would need some thought as to why the system is needed, and what could be done to prevent such a system being needed.
Ryan H., on 28 March 2012 - 08:46 AM, said:
- Adding the ability to opt groups into tighter mandatory security policies. (5)
I'm all for this, if I as an admin want to force my users to have upper case, numbers, and all manner of junk in their passwords, then I should be able to. Again though, this boils down to the cost vs benefits need to be weighed up. Will enough admins make use of it to warrant IPS developing it or is it an option that is better suited to an add-on?
Ryan H., on 28 March 2012 - 08:46 AM, said:
- Disabling account recovery for any group with moderator or administrative privileges.
What's the use-case for this one? I'm not sure why you would want to do this.
Ryan H., on 28 March 2012 - 08:46 AM, said:
- Expanding administrative logging, and removing the ability to delete those logs. (6)
I'm all for logging every single admin action, IP.Nexus-style, but again, this is just a forum and database sizes need to be considered. How large would the admin_logs table be for a large site with 5 admins that has been running for 6 years? Also, these logs exist elsewhere. Apache for example logs every request and it is unlikely that these could be easily deleted by someone who has gained access to your ACP. Is duplicating this information in your ACP really needed?
Making the admin logs impossible to delete would also be tricky. Removing options from the ACP is fine but stopping them from just dropping the admin_logs table, or selectively deleting rows is a different matter.
At this stage, I think that the only option is to restore your site from a pre-hack backup rather than trying to see what the hacker has done and trying to undo their changes.
So to summarize: Slow down remote brute force attempts and use a slow crypt method, those are the options that get my vote
#2233702 Real tags? Is it possible, these are useless.
Posted
on 22 February 2012 - 09:01 AM
Ah, I went ahead and FURLed up the tags because it was easy enough to do.
board/tags/{app}/{tag}
board/tags/{app}/{tag}
#2187869 Improve "error" message for visitors
Posted
on 27 October 2011 - 02:53 AM
Sometimes guests don't get to see the whole deal until they either sign in or register. This may apply to add-ons like IP.Gallery or IP.Blog. If guests are not allowed to see content, they get this harsh reply "An Error Occurred" which lets probably a lot of users feel bad and some may just leave.
Why not tell the visitors what to do instead in order to gain access to the content they are looking for and save one click by just sending them to a page where they can log in or register.
Check out the mockup and the original message.
Why not tell the visitors what to do instead in order to gain access to the content they are looking for and save one click by just sending them to a page where they can log in or register.
Check out the mockup and the original message.
Attached Thumbnails
#2180820 Bring back the 3.1 standard editor as an option
Posted
on 11 October 2011 - 03:24 AM
Yeah, it has the ability but it's a fair bit of work. We have actually discussed this internally quite a bit and it's something we want to do. Right now our priority is to stabilise IP.Board and its apps before we look at adding new functionality.
So, we hear you and we agree that buttons on the STD editor would be nice. It's more of a case of 'when' than 'if'.
So, we hear you and we agree that buttons on the STD editor would be nice. It's more of a case of 'when' than 'if'.
#2180805 Bring back the 3.1 standard editor as an option
Posted
on 11 October 2011 - 12:22 AM
kenichi tanaka, on 10 October 2011 - 03:49 PM, said:
I have to admit that I enjoyed the BBCODE version of the post box. But, I've noticed that when you select the BBCODE version by clicking the metal grey box icon in the upper left hand corner of the "formatting" menu, that it tends to block every feature out by "graying-out" every formatting feature so that you have to manually type in the BBCODE. Saying that this is annoying is understating the obvious.
#2178198 Bring back the 3.1 standard editor as an option
Posted
on 03 October 2011 - 06:47 PM
bfarber, on 03 October 2011 - 10:31 AM, said:
We will be investigating buttons in simple mode at some indeterminate point in the future, based on the feedback received.
#2178062 Bring back the 3.1 standard editor as an option
Posted
on 03 October 2011 - 10:31 AM
We will be investigating buttons in simple mode at some indeterminate point in the future, based on the feedback received.
#2176620 Bring back the 3.1 standard editor as an option
Posted
on 28 September 2011 - 09:36 PM
Some bugs/issues in the CKEditor on IPB 3.2.1 and 3.2.2. I'm using Chrome, a fairly popular web browser.
Bugs
- Various code disappears when transferring between the two modes or when initiating an edit in Rich Text mode. e.g. HTML line break tags, among others.
- Various code is added when transferring between the two modes or when initiating an edit in either mode. e.g. extra spaces, or via conversion of emoticon BBCode into an HTML image statement.
- Clicking on a button that is supposed to open a prompt (e.g. Image or URL prompt) sometimes lights up the window but fails to load the prompt.
- Some prompts (e.g. Code prompt) attach themselves to the top of the window and can't be moved vertically.
- Clicking on the resizer jumps the page up, making it an arduous ordeal to actually resize the editor.
- Sometimes the editor drops outside of the table it is contained within (I've seen this happen on the default IP.Board skin).
- Sometimes, attempting to initiate editing or save an edit using the CKEditor does not work.
- Occasionally, after loading a page with a CKEditor, the text area itself appears but no buttons appear, nor apparently the ability to use the text area, and it is virtually unusable as an editor.
- Occasionally the entire CKEditor itself completely fails to appear despite the rest of the page loading.
- AutoSave doesn't seem to do its job, based on my experiences.
Issues
- BBCode buttons don't appear in the Plain Text mode. That's just silly!
- Can't upload images directly using the Image prompt; need to upload an attachment first. WTF!
- Can't specify URL display text in the URL prompt; need to do it manually. LOL!
- The Copy function appears to be currently disabled.
- Some buttons don't bring up prompts like their similar neighbors do. e.g. Quote vs. Code.
If anyone sees anything here that isn't in the Tracker, feel free to report it.
Bugs
- Various code disappears when transferring between the two modes or when initiating an edit in Rich Text mode. e.g. HTML line break tags, among others.
- Various code is added when transferring between the two modes or when initiating an edit in either mode. e.g. extra spaces, or via conversion of emoticon BBCode into an HTML image statement.
- Clicking on a button that is supposed to open a prompt (e.g. Image or URL prompt) sometimes lights up the window but fails to load the prompt.
- Some prompts (e.g. Code prompt) attach themselves to the top of the window and can't be moved vertically.
- Clicking on the resizer jumps the page up, making it an arduous ordeal to actually resize the editor.
- Sometimes the editor drops outside of the table it is contained within (I've seen this happen on the default IP.Board skin).
- Sometimes, attempting to initiate editing or save an edit using the CKEditor does not work.
- Occasionally, after loading a page with a CKEditor, the text area itself appears but no buttons appear, nor apparently the ability to use the text area, and it is virtually unusable as an editor.
- Occasionally the entire CKEditor itself completely fails to appear despite the rest of the page loading.
- AutoSave doesn't seem to do its job, based on my experiences.
Issues
- BBCode buttons don't appear in the Plain Text mode. That's just silly!
- Can't upload images directly using the Image prompt; need to upload an attachment first. WTF!
- Can't specify URL display text in the URL prompt; need to do it manually. LOL!
- The Copy function appears to be currently disabled.
- Some buttons don't bring up prompts like their similar neighbors do. e.g. Quote vs. Code.
If anyone sees anything here that isn't in the Tracker, feel free to report it.
#2175994 Bring back the 3.1 standard editor as an option
Posted
on 27 September 2011 - 10:07 AM
Heyhoe, on 27 September 2011 - 06:35 AM, said:
It's all well and good saying "We know how to use BBCode as we have used it on forum software for years"
But what about new users? I'm currently attracting a lot of forum virgins, and the new editor makes it much more simple for them. I agree that the ability to switch a board to the 3.1 standard non RTE editior would be useful for some communities. But i certainly think the current route IPS is taking is the correct one.
But what about new users? I'm currently attracting a lot of forum virgins, and the new editor makes it much more simple for them. I agree that the ability to switch a board to the 3.1 standard non RTE editior would be useful for some communities. But i certainly think the current route IPS is taking is the correct one.
However at the same time there are plenty of sites with users who are experienced in the use of forum software and who simply find an RTE frustrating.
I am not suggesting CKEditor be ditched entirely, nor that IPS try to simultaneously maintain two different rich text editors. I am just asking for the fully-featured 3.1 standard editor to be restored as an option so that those who want to use it can do so. Since that editor is essentially just a textarea with some simple script to handle the insertion of bbcodes, I doubt there would be much ongoing effort required to keep it compatible with evolving browser standards (one of the main reasons given for moving to a third-party editor).
#2175973 Bring back the 3.1 standard editor as an option
Posted
on 27 September 2011 - 09:13 AM
Matt, on 27 September 2011 - 06:12 AM, said:
What frustrates you? I'd like to know. If we're going to improve the editor, then the more information you provide, the better.
#2174799 Bring back the 3.1 standard editor as an option
Posted
on 24 September 2011 - 11:21 AM
Marcher Technologies, on 24 September 2011 - 10:22 AM, said:
Maybe this is JUST ME, but i feel the horse is being placed in FRONT of the cart here...
STD integration should be a higher priority than RTE....
AS once the STD is sorted... the RTE NATURALLY follows suit.
STD integration should be a higher priority than RTE....
AS once the STD is sorted... the RTE NATURALLY follows suit.
#2174751 Bring back the 3.1 standard editor as an option
Posted
on 24 September 2011 - 09:15 AM
Apologies in advance for the length of this post.
It seems to me that most people who are seriously unhappy with the switch to CKEditor - including myself - are primarily users of the non-RTE mode.
The standard mode of the 3.2 editor has so far proved to be very buggy - I personally have submitted 8 different bug reports in the last 3 weeks related to it. Most serious was a bug involving the img tag which allowed an attacker to insert any arbitrary Javascript which would run whenever the post was viewed (you won't see this bug in the tracker as it was made private - it is fixed in 3.2.3).
Bugs aside, we also have the complete removal of bbcode insertion buttons in the standard mode. You have to type every single tag manually. I haven't used a forum editor for many years where this was required.
Also, the autosave function which was touted as one of the major advantages of the new editor, does not function in standard mode. I'm not sure if this is intended or a bug - I've submitted an issue in the tracker to find out.
I know there were many complaints about the RTE mode of the 3.1 editor. However, I'm not aware of any complaints from users of the standard bbcode mode. Personally I was extremely happy with it, the buttons saved me a lot of time and I never experienced any problems with it. My members were happy too, and all knew how to use it because the concept of bbcode has been standard across forum software for many years.
In short, there's are no advantages to the 3.2 editor for standard mode users, and many disadvantages.
The primary issue given in Matt's blog back in February for changing to CKEditor was the difficulty of maintaining and developing a rich text editor with constantly evolving browser standards. So the decision does seem to have been driven by the RTE mode.
My suggestion therefore, is this. Bring back the 3.1 standard editor, without its RTE mode.
Make it possible for admins to choose between using CKEditor, with its two modes, and the 3.1 bbcode-only editor as the default option. Let members choose too in their User CPs. Those happy with CKEditor could continue to use it, while those who are upset by all its missing functionality and bugginess can switch back.
IPS wouldn't have to maintain its own proprietary rich text editor as this mode would only be available for those choosing to use CKEditor. And presumably the amount of development involved in making the standard 3.1 editor compatible with IPB 3.2 would be minimal, compared to further hacking CKEditor to support raw bbcode insertion.
I would be more than happy to sacrifice the ability to switch between standard and RTE modes in the editor if it meant I could get all the other 3.1 functionality back. It seems like all the development time needed to adapt the 3.2 editor to restore full bbcode functionality is a waste when you could probably satisfy most complainants by simply integrating the 3.1 standard editor and giving admins this option.
Please at least consider this. Not everyone wants to use a rich text editor on forums.
It seems to me that most people who are seriously unhappy with the switch to CKEditor - including myself - are primarily users of the non-RTE mode.
The standard mode of the 3.2 editor has so far proved to be very buggy - I personally have submitted 8 different bug reports in the last 3 weeks related to it. Most serious was a bug involving the img tag which allowed an attacker to insert any arbitrary Javascript which would run whenever the post was viewed (you won't see this bug in the tracker as it was made private - it is fixed in 3.2.3).
Bugs aside, we also have the complete removal of bbcode insertion buttons in the standard mode. You have to type every single tag manually. I haven't used a forum editor for many years where this was required.
Also, the autosave function which was touted as one of the major advantages of the new editor, does not function in standard mode. I'm not sure if this is intended or a bug - I've submitted an issue in the tracker to find out.
I know there were many complaints about the RTE mode of the 3.1 editor. However, I'm not aware of any complaints from users of the standard bbcode mode. Personally I was extremely happy with it, the buttons saved me a lot of time and I never experienced any problems with it. My members were happy too, and all knew how to use it because the concept of bbcode has been standard across forum software for many years.
In short, there's are no advantages to the 3.2 editor for standard mode users, and many disadvantages.
The primary issue given in Matt's blog back in February for changing to CKEditor was the difficulty of maintaining and developing a rich text editor with constantly evolving browser standards. So the decision does seem to have been driven by the RTE mode.
My suggestion therefore, is this. Bring back the 3.1 standard editor, without its RTE mode.
Make it possible for admins to choose between using CKEditor, with its two modes, and the 3.1 bbcode-only editor as the default option. Let members choose too in their User CPs. Those happy with CKEditor could continue to use it, while those who are upset by all its missing functionality and bugginess can switch back.
IPS wouldn't have to maintain its own proprietary rich text editor as this mode would only be available for those choosing to use CKEditor. And presumably the amount of development involved in making the standard 3.1 editor compatible with IPB 3.2 would be minimal, compared to further hacking CKEditor to support raw bbcode insertion.
I would be more than happy to sacrifice the ability to switch between standard and RTE modes in the editor if it meant I could get all the other 3.1 functionality back. It seems like all the development time needed to adapt the 3.2 editor to restore full bbcode functionality is a waste when you could probably satisfy most complainants by simply integrating the 3.1 standard editor and giving admins this option.
Please at least consider this. Not everyone wants to use a rich text editor on forums.
