My question is related to the recommended way (going forward) to talk to on-premises Exchange mail box and perform operations on it from an external application programmatically?
EWS APIs and the corresponding SDKs look promising based on a few articles such as this :
https://blogs.msdn.microsoft.com/webdav_101/2018/06/19/about-using-ews-and-powershell/
but there is bit of confusion on whether it will continue to be supported in the future based on this:
https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/
Although the above talks of just o365, the fact that EWS will no longer be invested in, raises the question if new applications for on-premises exchange should continue to use it.
PowerShell, remote PowerShell etc. also might work but it seems less suited for use/integration within an external application and more so for automating operations.
Could someone please throw some light on what is recommended way going forward to work with on-prem Exchange?
Try the Microsoft GraphAPI. Details https://developer.microsoft.com/en-us/graph/graph-explorer here. Sign in. Try the https://graph.microsoft.com/v1.0/me/messages sample. See more examples by clicking "Show More samples" on the left column after you login.
Is it The Way (tm)? I don't know but is very cool. I have some sample code I'm working with, nothing in a format to share, but look like the API covers a lot of territory. Some client-only rules look like they need some work to expose, maybe they'll get beefed up in later releases.
Depends on the type of Application you are trying to write, EWS is going to be around in Exchange 2019 so it will work just fine talking to say 2013, 16 and 19 OnPrem. There are advantages and disadvantages to using EWS vs. the new REST API's but it is application specific and changing fast. But again it depends entirely on the type of Application you are trying to write and what version of Exchange you need to support. And typically newer features that will appear in new OnPrem versions aren't back-ported into older versions. So a great new feature that will work in Office365 and Exchange 2019 may not work in 2016 and you may need to use some of the older legacy API's to achieve the same thing. Bottom line as of today if you are an ISV and need broad coverage support for versions of OnPrem Exchange expect to need to use both EWS and REST. If you are just creating apps for one organization that's going to be migrating to 2019 in the future you'll probably get away with just REST.
Does anyone know the status of Kubernetes federation v2? I mean which of the goals specified in the "Cluster Federation v2 API Structure and Workflow
" document are already addressed and which are not? In particular, I would like to know if policy-based resource placement is already supported?
Thanks
It's still pretty much a WIP. I believe you can find most of the information in their community page
I would strongly suggest going through their meeting notes and their recordings. Also, if you have any specific questions feel free to join the meetings.
Update: There are newer projects addressing the same problem. For example:
Karmada
I originally posted this question as an 'answer' to:
Can a single company really not use QB API?...Semi Rant
but am reposting, because it is a question.
The original poster and I face a similar problem wanting to use the QBO API for an application designed for a single company. What would be the disadvantage of connecting my app to my QBO account using the intuit development server indefinitely, i.e., never take my app through the production qualification process?
Thank you.
I believe that is possible but then you can use at max 10 developer connections.
As we already mentioned we do not not support custom integrations at this time.
Even we wouldn’t recommend moving you to production as it would cost us $1k per year to security review it, and we would only recover about $60 per year in connection fees.
So, the disadvantage for you will be in terms of number of connections, limited support and your app vulnerability since it has not gone through the security review process.
Please read the policy docs mentioned here:
https://developer.intuit.com/docs/0025_quickbooksapi/0005_introduction_to_quickbooksapi/z_developer_policies_and_guidelines
Edit for the question asked:
When you login into developer.intuit.com, Go to Manage My Apps, then click your app.
You will see the number of connections for that app under Test connections.
It refers to the numbers of company files your app is associated with or has been authorized to access data.
First
No I am not asking you to teach me hacking, I am just curious about this file and its content.
My journey
When I dived into the new HTML5 Boilerplate I came accross the humans.txt. I googled for it and I came at this site http://humanstxt.org/.
Immediately my attention went to this picture:
Do I read this correctly? Hackers.txt?
So I resumed my journey in google and stopped at this articles
When I started reading this I had the feeling that its about the difference between Hackers and Crackers. Later I got the feeling that I'm might be wrong and that this place is that this hackers.txt file is a sort of guestbook for hackers?
Also other examples about hackers.txt files I found here
Some files contain code, others have just hurtfull information.
Now I'm realy confused, guestbook, hack tutorials or just history?
Question
What is the use of this hackers.txt file?
The way I see things:
robots.txt contains information and instructions for robots (so it should be read/used by web crawlers, spiders and other kind of bots)
humans.txt contains useful information to be consumed by humans, according to http://humanstxt.org/
hackers.txt should be targeted towards hackers, so it should contain any information the site owner might want to transmit to a hacker, as Ze'ev pointed out. I don't think this should be a place for hackers to write anything, but rather to get information from the site owner (perhaps on how to report vulnerabilities, as others suggested).
Commonly known as Eduardo Vela, Eduardo A. Vela Nava (or sirdarckcat on Github and Twitter) has been a Security Engineer at Google since 2010. (He currently has the role of Product Security Response Team Lead).
As other security experts before him, he pondered the issue of effectively communicating the details of a site's vulnerability reward program to white hat hackers/pen-testers.
One specific such person is Chema Alonso (also on Twitter).
He is well-known enough to warrant a Spanish Wikipedia entry
Between 2005 and 2011 Alonso was awarded the Microsoft Most Valuable Professional Award for Enterprise Security 6 years in a row. That should tell you something about his "skillz".
On February 3rd 2011 Alonso wrote about his frustrations regarding the topic of communication between the administrators and/or developers of a site and hackers.
He proposes a similar initiative as humans.txt but for hackers. As he mentions this hackers.txt initiative in his blog-post.
In April 2011 The humanstxt.org website got a new design which includes the image which mentions the hackers.txt file.
At this point, I must sadly submit to conjecture, but... consider:
The team behind humans.txt are all from Spain (mostly Barcelona)
At this point Alonso is already quite well known in the Spanish developer community
Would it be such a far stretch to imagine that they got to know of each other's efforts?
On May 14th 2014 Vela, already working at Google, commented on a blog-post by Alonso. It is most likely that they had further contact in a professional setting. Whether or not thay extively shared their idea's regarding anything related to hackers.txt is unknown.
On July 6th 2017 Vela posted a question to this extent on twitter:
How about we create a /hackers.txt that says whether something is in scope or not of a vulnerability reward program and where to report it?
Subsequently, an empty git repository was created for hackerstxt.org on github
and an email thread was opened at Google Groups to discuss this idea further.
On August 13 2017, Edwin Foudil (or EdOverflow on Github and Twitter) created a git repository for security.txt on Github and responded to the mailing list:
I have published a similar project to the one being discussed in this group (https://github.com/EdOverflow/security-txt) and would love to get some of your feedback and ideas.
The project is the equivalent of robots.txt, but for defining a security policy. Companies can add a security.txt to their website and define clear guidelines of what security researchers must do when they discover a security issue. security.txt also allows bug bounty programs to add their scope there. security.txt uses a similar syntax to robots.txt, which should make it easier for machines to parse.
He was, in part, inspired by an open-source project he was working on at the time called GratiPay. GratiPay had a SECURITY.txt file since 2013.
His inspiration also drew from the SECURITY.md files that more and more open-source projects were adding to their repositories.
On September 10th 2017, Foudil submitted a first draft for security.txt to the Internet Engineering Task Force.
On September 14th 2017 Alonso wrote a blog post with the title (translated from Spanish) "Security.TXT an IETF draft for my Hackers.TXT".
Beyond the title, Alonso does not allude to the fact that his 2011 idea was the origin of the draft but he does state his approval of the effort.
On February 3rd 2018, the mail group was informed to concede to security.txt and Vela tweeted that Google had already implemented one.
Further information
Details and a nifty tool to generate your own security.txt can be found at
https://securitytxt.org/
Adoptation
Even though the RFC is still in draft, the standard is already being adopted quite well by major players on the web.
Besides the security.txt at Google, there is also one on the website of:
1password
BBC
bit.ly - http://bit.ly/security.txt (can't be linked because StackOverflow blacklist the use of common link shorteners in posts)
CERT NZ
DailyMotion
Dropbox
Facebook
Github
haveibeenpwned
NodeJs
NPM
Open SSL
Shopify
(Feel free to add more from well-known sites, if you find 'm)
As with humans.txt, there also seems to be a hackers.txt site at http://www.hackerstxt.org/. I'm not sure if someone has set the site up as a joke or not, but it links to a blog post on someone's Blogger site.
The post rambles on a bit (I put it through Google Translate) about the poster's history as a 'hacker'. Anyway, towards the end the writer says:
therefore believe we should promote an initiative type hackers.txt , in which managers leave us a message to potential "aliens who are good" that makes it clear they will do managers receive a report of a vulnerability in your site. I've been circling this , the truth is that it is difficult to finish shaping, because perhaps some "alien who is not so good" , type Brainiac , take a free hand to brush a site, or the "good board administrator" , decide to change your mind and Liem, but I think we should be able to do something, I dunno, maybe having Jon Jonz , or perhaps thinking about how to write that file hackers.txt . How do you see it? Greetings Evil!
So I assume that the poster wants to start a sort of hackers.txt standard in the vein of humans.txt, but hasn't finished it off, or hasn't gotten it into the English speaking world.
Digging around, the Blogger site seems to be owned by a guy called Chema Alonso, who must be fairly reputable in the world of Spanish programmers as he has about 35k Twitter followers (https://twitter.com/chemaalonso). He seems to work for a company called ElevenPaths (http://elevenpaths.com/), which says that it's driving "radical innovation in security product development". A quick Whois check shows that the hackerstxt.org domain is registered by someone in Madrid, so I would assume it's Alonso.
The .txt file over at http://www.textfiles.com/news/hackers.txt, which has been refered to by some of the other answers in this thread, doesn't seem to have anything to do with the hackers.txt reference over at http://humanstxt.org/, and neither do most other search results for 'hackers.txt'.
It's possibly a joke, but If humans.txt is for humans to read then maybe hackers.txt is a warning for hackers.
Like the notice you get when you SSH into some more public terminals. "You are being watched... we will get you if you do anything bad..." That sort of thing.
If a hacker did compromise the site, the might notice the file, read it, realise you mean business and be scared away!
Interesting idea.
As this question is somewhat open, I think you are also expecting some assumptions, I write here (not in a comment) my opinion, but if it should be there, I'm sorry.
I think that the idea lying behind humans.txt (which I heard of before) is to make a new habit, new style or something like that. In fact, you can put a contact page, where all these data from humans.txt can be put. I think that hackers.txt could be also something like new style.
I suppose that hackers.txt was much earlier, maybe for 20 years, when www servers and popular web knowledge was poor, when using localhost Apache+PHP+MySQL was making you "a hacker", and if someone could access the file other than index.html (and linked pages from this), reading hackers.txt was some kind of prize, or maybe some kind of filter to show some information to "those who behold" (like this one perhaps).
I think hackers.txt should contain notes on how the site owner would like for data to be used... E.g. "I don't mind if you scrape the movie listings, but please don't hot link out images in your app"
The documentation here and here seems to be saying that I can only filter strings with exact matches "Supported Operators for Strings :EQUALS:"
I'm using the IPP .NET Devkit so my search looks like this:
CustomerQuery qboCustomerQuery = new CustomerQuery();
qboCustomerQuery.Name = "Southwest";
List<Customer> customers = qboCustomerQuery.ExecuteQuery<Customer>(context).ToList<Customer>();
However I need to find a customer name that contains "Southwest" in it. Is my only choice really to cache the customer names locally and search my own db? This seems asinine. Please tell me I'm being an idiot and that this system isn't really this obviously broken.
Unfortunately, the Intuit Anywhere APIs really are this crappy at the moment. :-(
Here is the list of filter operations that are supported for strings:
https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0400_QuickBooks_Online/0100_Calling_Data_Services/0030_Retrieving_Objects#Supported_Filter_Operators
Note that the only one supported is:
:EQUALS:
Ick!
Fortunately, Intuit is hard at work on the v3 APIs. It was rumored that v3 will support better filtering.
Unfortunately, Intuit is doing their usual thing and not involving developers in the v3 dev process anymore, so we really won't know whether or not v3 is going to suck until it's actually released. sigh You'll notice the last update about v3 data services was in October by Wei... unfortunately Wei isn't even on that team at Intuit anymore, so who knows what the status is, or even if there's anyone at all working on v3 anymore at Intuit.
I had to do something similar. Sadly, as Keith pointed out, it is not yet supported. What I ended up doing with this was fall back on LINQ.
I read in all of the customers, and then filtered using LINQ. This prevented me from having to write and read from a db and speed things up by keeping the data in memory.
So, for now, try LINQ. Hopefully we will get a better solution when v3 comes out.