Disqus - Latest Comments for ahmadnassri

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Thu, 21 Nov 2019 12:55:21 -0000

I belive they are shipped at random.

as the per the Vivint agreement (at the time that I had used them) I recall that if you pay the full price for your hardware, you are entitled to the passwords, so if you contact them they will be obligated to provide them ... especially if you stoped using the service.

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Wed, 07 Nov 2018 06:30:52 -0000

I'm not aware of any method to do that without using alarm.com, where did you get your hardware from? was it from an alarm.com vendor?

usually you can ask your vendor to give you the credentials if you paid full price for the hardware

Re: RESTful services with Zend Framework 1.0

Ahmad Nassri — Mon, 02 Jul 2018 18:26:49 -0000

I have not touched ZF1 in years, I'm afraid I can't help you debug your question. sorry.

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Mon, 19 Feb 2018 20:00:54 -0000

it still works for me and for some other users, but not for everybody, my guess is they updated their hardware, and with it, new customers are seeing a different web experience / page for the cameras than others, so your cameras might be newer hardware.

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Thu, 25 Jan 2018 06:03:14 -0000

agreed! it does seem that they have been working on updating their entire front-end, though it seems to be little more than a design lift, and while the `LiveViewFlash.aspx` page is the default, the old one is still accessible manually by typing-in the URL ... thus no real fix yet.

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Thu, 07 Sep 2017 00:19:26 -0000

I've read in online forums that people have called and demanded their passwords to the camera hardware AFTER they cancelled plans / video package (since you're paying for the hardware, it's your property) so they should be giving it to you once you cancel the video package.

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Sun, 27 Aug 2017 22:57:16 -0000

try different browsers, it might be a server-side redirection ... it could also be segmented by account type, I can still get to the page on my account!

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Mon, 01 May 2017 23:56:48 -0000

some cameras started shipping without the web interface, others might have separate config for admin settings.

try looking up the API, you can do everything through the API with the credentials

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Mon, 01 May 2017 23:35:57 -0000

excellent! enjoy!

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Mon, 01 May 2017 21:42:35 -0000

by "not able to connect" what exactly do you mean?

not able to access the camera over the network?

password works but no view?

decrypted password just doesn't work?

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Mon, 01 May 2017 19:49:17 -0000

following the instructions, you should see a key under "ConnectionThread.class" which in my example is marked as "redacted"

Re: Alarm.com Camera Vulnerability Exposed

Ahmad Nassri — Fri, 17 Feb 2017 07:40:24 -0000

try this: https://jsfiddle.net/ahmadn...

Re: Snapchat opens Toronto office

Ahmad Nassri — Tue, 07 Jun 2016 14:19:43 -0000

gotta get those SR&ED dollars ya'll!

Re: Kong API and Microservices Management

Ahmad Nassri — Fri, 18 Mar 2016 18:32:32 -0000

nice job!

Re: Kong, the API/Microservice Management Layer with Ahmad Nassri - Three Devs and a Maybe

Ahmad Nassri — Mon, 21 Dec 2015 15:42:51 -0000

Thanks so much for hosting, lots of fun!

Re: The Story So Far: My Journey (Part 2)

Ahmad Nassri — Tue, 24 Nov 2015 17:33:53 -0000

Thanks Jerod! lets hope your wifey doesn't find this comment online, else you'll be busted ;)

Re: Managing Change Behind the Scenes with Continuous Regression Testing for a Seamless Customer Experience

Ahmad Nassri — Tue, 27 Oct 2015 21:21:58 -0000

Interesting approach I do like the date and point in time aspect. Seems more natural than arbitrary numbers.

Curious, this approach means that once a user "upgrades" there is no turning back, meaning the you can't have a graceful upgrade path and certainly no rollback?

or is there more to it than what's described here?

Re: Establishing A Common API Definition That API Management Providers Can Use

Ahmad Nassri — Thu, 15 Oct 2015 21:03:58 -0000

did you want to approve my second comment marked as spam detailing some technical feedback?

Re: Establishing A Common API Definition That API Management Providers Can Use

Ahmad Nassri — Thu, 15 Oct 2015 20:14:17 -0000

(starting a fresh thread here so its a clean start)

> please submit your outline, of what you think a common outline for API management should be. Preferably this is a simple HTML outline accompanied by a machine readable version as 3Scale as come to table with. If I could find a single other API management provider who provided a complete stack of their features, I would have merged with this, making it even larger (and complicated).

I get you, too much work consolidating every different approach, and certainly many formats to keep track of too ... that said, almost all the providers (that I've seen) have an API documentation listed in HTML (but yes, not all in a doc format), here's ours: https://getkong.org/docs/0.... maybe you missed it, but its been up there from day one of launching Kong. happy to discuss any technical reasoning and sharing our ideas as well.

> You are saying that an API management business that has been around 4+ years longer than the one you work, and the outline I use for my own business that has been around 1+ years long than the business you work for is overly complicated. Not the way to start an interoperability conversation. So….since you kicked off with this tone, let’s go there.

No, I'm just not seeing a value in separating those objects, as to me they are the same / similar ... corporate affiliation aside and regardless of company history, lets talk about the reasoning, can you provide some details who those objects are separate / different, what value this brings and how that's useful to the API Provider (not just the API Tooling Company) I can't see the value, so please share some insight here.

> Let me see your outline so I can match with mine. What is the last line of this post?? “If you are one of the API service providers I track on, and have an API definition, make sure I have link so I can include in this portion of my research.” You are telling me the answer to interoperability between API management platforms is use KONG? Bullshit!! You know how many people have approached me telling me this? Just cause you are open source isn't going to sell me. I know the Mashape mission, and open source doesn’t convince me of anything. I held Alcatels hand through their open sourcing (vomit), and WSO2 product (enterprise) is derived from many conversations with me, long before Mashape ever even thoughts of opens sourcing shit!

Ignoring the language. No, I'm not forcing you or anybody to use one product over any other, I'm representing my point of view about the single "Consumer" object with reference to the implementation, which happens to be in Kong. what better example than an actual implementation? especially the one I've worked on. again this is not about corporate affiliation. If you don't want to use corporate products as an example, then I would say the same about your post, which is heavily skewed in your corporate affiliate's direction. but that's okay, because that represents the technical approach you choose and I can appreciate that, lets look beyond that and focus on the technology answers and clarifications.

> “If you are one of the API service providers I track on, and have an API definition, make sure I have link so I can include in this portion of my research.”

link above, its been the Kong documentation since day one. sorry its not in Swagger format ... that could be something to work on, but as you compiled that list here manually, so can we do the same with everybody's definitions so we can study them in detail and discuss.

> I count 10 separations in my API management proposal above? Break it out as you wish, it is why I provide as outline for discussion and as machine readable API definition. Nobody is saying it is all or nothing. Break it out man. Show me what you mean. I only use 78% of this outline for my business, and there was 30% more I cut out from 3Scales outline for this posted — tell me yours. Don’t tell me I’m wrong. If you follow links in the post, you'll see I've had previous discussions which had distilled versions of this -- where were you on those?

First, I've scanned the other posts of course, the links go deep and you can't expect everybody to read every-single-line you publish before engaging a conversation, if there's something obvious I missed, then I apologize, but to the topic on hand, as I clarified after, I'm referring to the idea of including Analytics, Portal, Monitoring etc ...as part of the an API Gateway, which I find excessive. You don't expect a Blogging platform to provide you Analytics, you use Google Analytics for that (or others), you don't expect an e-commerce product to measure user engagement, you use Mixpanel (or others) for that. Likewise, why do we in this industry insist on building a monolith of API Management tools, then preach Microservices as a great approach. Lets break those out *outside* the scope of API Management, I like the list you got so far, but I don't think Analytics should be part of it. I feel that's a separate product, with separate technology requirements. (also, I'm not quite sure what the "Service" endpoints are, I tried looking them up on 3scale's side, but didn't spend enough time yet)

> Again, interoperability requires me using your product. Fuck that. I want an interoperability definition, not another fucking vendor telling me I should use their product.

Again, I'm just referring to my point of views by example, I did not say "just use X" :)

> WTF does this even mean? I have even started listed out the analytics I’ve built on top of 3Scale infrastructure? This is my start, derived from the public outline that is 3Scale offering.

see my response two points above ^. my feeling is that the function of "Analytics" is beyond the scope of an API Management solution.

> focus on solving one problem, and excel at it, rather than gluing multiple technology pieces to solve multiple problems.

> I started with 1 problem in 2010 - API Management. In 2015 I have 20 core problems I am focusing on. You telling me I'm not excelling at it? Really? I suggest you check yourself. As I state, this is the first problem area I'm tackling. I am focusing on one problem, and moving to API monitoring next. I have 15 more to go this week alone. This is my attempt at solving. I know you have one fucking product to shove down people's throats, but I have an entire space to define--how about you go back to work.

admittedly, I could have phrased this better. I was referring and thinking of the "systems" and the tools (not you directly) when I refferd to splitting up the focus of each system to solve the one problem its meant to solve, and excel at it.

> Come back with an outline that I can merge and map to this please. Pretty please.

referring to what we discussed 1:1, I don't know if posting on my own blog and doing a ping-pong is really efficient ... which is why I started commenting here, you already got a thought and thread going, why not use the space ... but if you don't like the comments for discussion, perhaps https://github.com/api-stan... which is, as you recall started with a similar point to discuss: unifying and standardizing the API Management space, why don't you publish this outline there and engage the rest of the API Tooling developers already there?

Re: Establishing A Common API Definition That API Management Providers Can Use

Ahmad Nassri — Thu, 15 Oct 2015 20:13:16 -0000

okay, this is going to be a long response, which I honestly don't think is appropriate to a comment thread, but I feel my hand is forced here to provide some balance that I think is needed to this "conversation", so here goes.

first off, lets get the personal stuff out of the way, as I believe we can only accomplish value to the community by overcoming our own personal biases and accepting feedback and criticism from others while maintaining diplomacy throughout.

you say you're a "nice guy", yet you quickly jump to throwing "diplomacy out of the way" as you put it, and start with making this a competition of some sorts? with use of strong abrasive language.

you're reading a "tone" into my comment? an article, nerveless a comment is just text published online, you cannot possibly expect to convey a full range of human emotion though it, never-mind assuming a "tone" out of it! this is quite shocking to me.

the world, and therefor the Internet is made up from mixed backgrounds, cultures and languages, you're a well traveled guy and you should know a worldly conversation doesn't start with assumptions, nor taking offense at any gesture or words used without getting context and understanding the other's background and point of view.

You seem to think I'm attacking in some way? which is not only surprising, but also sad to see, I came here to express feedback and share some opinion on a topic that's very dear and near to my heart, regardless of corporate attribution. I assumed we're professionals, so giving direct feedback shouldn't be a problem. I did not expect having to list my entire resume for you first, then asking for permission to provide feedback.

this is a public post on a publicly accessible domain with an open comment thread, referring to it as your "workbench" is all fine and well, but you don't seem to want opinions or feedback, your responses and language used is certainly not "nice", both in your response to me and others. what you're saying is anything but nice. a nice person is always nice. not conditionally with select audience.

if you don't want open and honest feedback, don't publish online and certainly don't open up a comment thread. and to be clear, I'm not trying to be abrasive, this is just an opinion. my opinion. please don't read a tone into it, there is none other than a friendly tone with a calm representation of my point of view.

If you want to get a sense of my tone, then lets jump on a video conference where I can convey further dimensions of human interaction beyond just text.

I want to continue the technical discussion, because I genuinely find it valuable, but I'm discouraged to have one with you if you're going to continue use language such as: "WTF", "Bullshit", "Fuck" and so on ... and I'm going to have to overlook all the cheap shots at myself or my CEO (who by the way is too busy *running a business* to engage online with every post or API discussion)

I have the patience and courage to continue this discussion despite this setback, and can look beyond your choice of language, but think of the many people out there who see responses like yours to my comment, they just immediately distance themselves, shying away from this discussion. How is that helpful to the community? you said you're doing this for the community? I too want to include the community, but I want to be inclusive and get as many people involved as possible to get the most amount of knowledge shared, rather than distancing people and going at it alone.

final thoughts: please don't worry about my feelings, I'm not hurt, I'm saddened that you read too much into what was a quick and simple feedback and turned it into this long thread that seems personal for some reason (although I don't find it to be). I do like making friends, regardless if that's your goal or not, there world is better with friends than without. I'm already moving past this, as my real focus and passion is on the technology and solving real problems, also, my personal judgment of you is not of what past accomplishments may be or what you might have responded with today under what's clearly a false assumption, I judge on action, lets show the community we can provide value, beyond personal biases and then I'll be a supporter.

since this is already a long response, I'll start the Technical response in another comment, hopefully putting away personal biases, and continue this discussion with just the technology in mind. (I'm also ignoring the other threads and just focusing on this one).

Re: Establishing A Common API Definition That API Management Providers Can Use

Ahmad Nassri — Thu, 15 Oct 2015 13:41:33 -0000

this is an overly complicated list, starting with "application" vs. "user" vs. "account", those don't need to be separate entities, but rather the same entity with different declaration of "type" it adds little to no value to the end consumer of the API...

which is why in Kong (https://getkong.org/) we have an abstract "Consumer" entity that the API owner can choose to treat as a user, application, account, etc ... a Consumer is provisioned credentials for different authentication methods, and they are at liberty to use whatever authentication method they choose (having been enabled by the API Owner)

another issue I find common to API management platforms is the "Jack of all trades, Master of none" scenario ... where functionality beyond the scope of "management" are added on top and bloating the system, the prime example here is Analytics ... which by all definitions is a completely separate system, with separate standards on technology stack than what an API Management would require.

Which is again why, at Mashape, we launched Galileo (https://www.apianalytics.com/) as a standalone API Analytics platform.

an API Management solution should of course provide reporting functionality, but not "analytics" on said reports, that's a separate system's job.

focus on solving one problem, and excel at it, rather than gluing multiple technology pieces to solve multiple problems.

Re: A Common, Open Source API Design Editor Is Needed For API Service Providers

Ahmad Nassri — Fri, 14 Aug 2015 16:28:23 -0000

been actually thinking along the same lines, and have approached some folks about the same idea (Gelato, Runscope, APIMatic) ... we should sync up and get this going!

Re: A faster Google Analytics implementation

Ahmad Nassri — Mon, 20 Jul 2015 09:54:06 -0000

this is an old article referencing the OLD Google Analytics code, for the up-to-date version please check here: https://www.ahmadnassri.com...

you should probably not use the "ss-google-analytics.com" URL, unless you're still on the old version of Analytics Code, which you should also update to the latest :)

Re: Mashape Opens Kong, a Microservices API Gateway Built on Nginx

Ahmad Nassri — Tue, 28 Apr 2015 19:50:25 -0000

Loving the choice of graphic, really speaks volumes! and certainly reflects how we feel after months of hard work prepping Kong for its first public debut!

Re: What is a 'Software Architect' and should they write code?

Ahmad Nassri — Mon, 13 Apr 2015 13:27:08 -0000

Thanks, I think you left your comment on the wrong article though, I'm assuming you were referring to this one: https://www.ahmadnassri.com...