Cometchat is it actually using comet? - comet

So someone's selling a comet chat solution:
http://www.cometchat.com/
But I think it might be a misnomer, because I don't think it actually uses comet.
Can someone confirm whether or not it's actually a comet based chat, or just o' ajax.
Thanks.

RTM - According to their FAQ they do not.
http://www.cometchat.com/support/page/faq?category=6

Actually that depends
Do you use true Comet technology?
By default CometChat is set to use smart-polling i.e. CometChat will poll depending on user activity. Taken from their website "If you activate our CometService, then CometChat will switch over to true Comet technology."
I suspect that you can also use true comet technology with cometchat in conjunction with ApeServer, BeaconPush or PusherApp, but you'd be best to email them directly to find out.

Related

How can I authorize/capture Paypal payments at a later date on Wix website?

I'm using Wix as an e-commerce solution and the way I understand it, I can only add code (not edit current code) to make specific changes to the site. The one change I want to make is to have the ability to authorize/capture PayPal payments at a later date for all the products I am selling.
I've read through the PayPal authorization/capture documentation here but am still confused for my specific use case considering the only button I have is a "Check Out with Paypal" once customers have added products to their cart as opposed to "Buy Now" or some of the other button options available.
Is there a way to easily integrate authorize/capture in this case and if so, can someone help me out with how? Hoping I can make one change no matter how many different products a customer is purchasing that allows me to either capture all or part of the entire purchase amount and void the rest.
I've scoured the internet, but don't feel like anything I've come across is directly applicable. See here and here. The latter link makes it look insanely easy, but again I think the problem lies in the fact that I'm using Wix and can't directly edit existing code.
If anyone can provide directions/code necessary to implement this I'd be extremely grateful. Thanks so much in advance!
Note: It appears Wix integrates with PayPal Standard and all I need is the "Basic Authorization" capability, NOT "Order Authorizations."
The latter link makes it look insanely easy, but again I think the problem lies in the fact that I'm using Wix and can't directly edit existing code.
You've nailed it. It would be that easy, just add the parameter paymentaction=authorization when redirecting to PayPal, but Wix needs to provide a way for this to happen.
Many shopping carts -- especially those that integrate via an API rather than Payments Standard -- have a checkbox in their settings to toggle on authorization mode vs. immediate capture (sale) mode. The reason API-based integrations are much more likely to implement such a setting, is that an API is needed for the shopping cart to be able to capture the authorization at a later point in time. API-less integrations (like payments standard) cannot do the capture themselves (because this requires an API call), and so with standard you'll always need to log into www.paypal.com for the capture later on.
Anyway, there's probably no way forward unless Wix provides you with one.
Wix could well be using an API integration rather than the HTML-only Payments Standard, but the problem is the same: the API needs to specify 'authorization' (instead of 'sale'/'capture'), and from their lack of documenting the feature it does not appear Wix has implemented this.
Most shopping cart/platform providers do support authorization and capture, so you could make the feature request to Wix, and/or consider switching providers if it's a must-have.
On a general note, using authorization and capture adds complexity to payment processing, and the capture is not guaranteed to be successful. You can get a successful authorization and then have the payment fail when you try to capture it (happens in a certain % of cases, when funds are no longer available or the card decides to decline). So in general, you use immediate sale/capture at checkout time (not authorization) unless you have very specific and well-defined business needs to not be capturing up front (and refunding in the case of exceptions).

how can i be sure that people cant view my code?

I would like to ask if it's possible for people to view code I can see in Microsoft debugger.
I'm probably just being paranoid, but can other people see my code using their debugger?
I can't see the password and login when I just enter view code, but I can in debugger. I'm pretty sure that I'm safe, but I cant afford to make a mistake.
In this case I Advice you for limit your client side codes and depend more on server side, Special for the valued algorithms and new ideas.
Php is a good simple way but if you want more security,
better to mix server side codes with ASP C# or java to have the ability of encryption, encoding, secured textString and ... cts.
Obfuscation could be another good option for you if you have client-side code you don't want easily viewed by others.
On the part where you can see login credentials: I believe you'll want to look into storing passwords as Salted Hashes. There are many other ways to ensure passwords stay confidential.
These are certainly not plug and play solutions by any means and I'd highly recommend doing your own research on these topics before doing so.

Best way to avoid fake users

I'm developing a web app where it's crucial that the users can't register twice (e.g., with different emails).
I'd like to use some automated way to check it's unique.
Checking Personal Identification Number (like in Passport), isn't a good idea, because it must be done manually, since gov sites use captchas.
What is the best way to achieve it?
To be more specific, what is a field that I can use with UNIQUE constraint in my users table?
I am afraid there is no single answer to your question. Tax systems use VAT code, medical systems use Social Security Numbers, Universities use Student-ID etc.
Depending on your application, you could try to see if OpenID would be suitable. It provides an easy sign-in mechanism for your site. OpenID will give you a lot of information about the user and also the advantage of access to social networking data which may be valuable to your application.
You can for example use DBMS and keep an eye on users registrations. For more info see msdn SQL Server

Is there a term that describes an application that gets smarter the more data it has?

A coworker of mine has asked me for a term (preferably an adjective) that can be used to describe a system that gets more "intelligent" as it gets more data. The example she used when asking me this question was "as Google crawls more sites, it gets smarter at searching".
Personally, the best I could think of offhand was "adaptive", but that doesn't feel right. Can anyone suggest something better?
Thanks!
Sometimes you refer to things like spam filters as "trainable". Perhaps that could apply here.
It could be a vague description of an expert system, which often have a learning aspect and use it to gain more "expertise" in their problem domain.
The domain of this kind of applications is "machine-learning". But I'm not aware of a matching adjective.
The example she used when asking me this question was "as Google crawls more sites, it gets smarter at searching".
Unlike learning algorithms, where the algorithm itself changes based on past success, Google searches get better due to improved ranking of the results bringing the best pages to the top. The quality of the PageRank algorithm's results increases due to the network effect of the input data - the more connections, the better the chance that the best connected page is the most relevant.
The rule that says the effect of a network is super-linear is Metcalfe's Law, so if the "smartness" of an algorithm relies on network effects you could call the algorithm "Metcalfian". I've no idea whether the quality of PageRank results is super-linear in the number of inputs though; if anything I'd expect it to be sub-linear, as once you have enough links in the network to get rid of noise the rankings should be stable.
What about the term "evolve" or "evolving."
How about "capable," or "robust."
Learning Artificial Intelligent software.
Skynet or Joshua/W.O.P.R.
I would call it Heuristic.
If it's a communications network, then it follows Metcalfe's law. You could call it Metcalfian. (You'd like be laughed at.)
I think the term is adaptive associative memory systems (leading to autonomy, perhaps).

Should you worry about fake accounts/logins on a website?

I'm specifically thinking about the BugMeNot service, which provides user name and password combos to a good number of sites. Now, I realize that pay-for-content sites might be worried about this (and I would suspect that most watch for shared accounts), but how about other sites? Should administrators be on the lookout for these accounts? Should web developers do anything differently to take them into account (and perhaps prevent their use)?
I think it depends on the aim of your site. If usage analytics are all-important, then this is something you'd have to watch out for. If advertising is your only revenue stream, then does it really matter which username someone uses?
Probably the best way to discourage use of bugmenot accounts is to make it worthwhile to have an actual account. E.g.: No one would use that here, since we all want rep and a profile, or if you're sending out useful emails, people want to receive them.
Ask yourself the question "Why do we require users to register to access my site?" Once you have business reason for this requirement, then you can try to work out what the effect of having some part of that bypassed by suspect account information.
Work on the basis that at least 10 to 15 percent of account information will be rubbish - and if people using the site can't see any benefit to them personally for registering, and if the registration process is even remotely tedious or an imposition, then accept that you will be either driving more potential visitors away, or increasing your "crap to useful information" ratio.
Not make registration mandatory to read something? i.e. Ask people to register when you are providing some functionality for them that 'saves' some settings, data, etc. I would imagine site like stackoverflow gets less fake registrations (reading questions doesn't require an account) than say New York Times, where you need to have an account to read articles.
If that is not upto your control, you may consider removing dormant accounts. i.e. Removing accounts after a certain amount of inactivity.
That entirely depends.
Most sites that find themselves listed in bugmenot.com tend to be the ones that require registration for in order to access otherwise-free content.
If registration is required in order to interact with the site (ie, add comments/posts/etc), then chances are most people would rather create their own account than use one that has been made public.
So before considering whether to do things like automatically check bugmenot - think about whether their are problems with your business model.
There are a few situations where pay-to-access content sites (I'm thinking things like, ahem, 'adult' sites) end up with a few user accounts being published publically (usually because someone has brute-forced some account details), and in that case there may be a argument for putting significant effort into it.
From an administrator viewpoint absolutely. That registration is required for a reason, even if it's something just as simple as user tracking/profile maintaining. Several thousand people using that login entirely defeats the purpose. IP tracking could help mitigate this problem, but it would definitely be hard to eliminate entirely.
No need to worry about BugMeNot: http://www.bugmenot.com/report.php
With bugmenot, keep in mind that this service is not actually there to harm the sites, but rather to make using them easier. You can request to block your site if it is pay-per-view, community-based (i.e. a forum or Wiki) or the account includes sensible information (like banking). This means in virtually all situations where you would think that bugmenot is a bad thing, bugmenot does not want to be used. So maybe things are not as bad as you might think.