Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Mike Noordermeer
@MikeN123
since there is no 'user consent' scenario for EWS, even with O365, I think it's fairly useless
if an admin needs to give full access, he can create a service account as well
Victor Boctor
@vboctor
I think OAuth gives benefits like: 1. app doesn’t see password, 2. constrained access, 3. ability to revoke. Would EWS OAuth give you 1 and 3, but not 2?
It would be use for developers of services / applications requiring such access rather than admin.
Mike Noordermeer
@MikeN123
EWS with application impersonation also gives you 1, and I'm not sure EWS OAuth gives you 3. on a per user basis
So essentially using OAuth with EWS instead of app impersonation is just swapping the (app specific) username/password for an OAuth token
Asbjørn Aarrestad
@ahaarrestad
anbyody got experience publising to sonatype?
the ticket is ok, so I guess we can start publishing snapshots any day now?
Mike Noordermeer
@MikeN123
afaik it's just a matter of configuring the deploy plugin in the pom.xml
but yesterday we discovered HEAD is currently borked with some firewalling configurations (e.g., TMG)
has to do with httpclient 4 cookie handling
still have to figure out a workaround for it
Asbjørn Aarrestad
@ahaarrestad
i have a local deploy at the moment, but want to change to a central one when available ....
Erik van Paassen
@evpaassen
Does anyone have experience with retrieving the EffectiveRights property of an Item while using a FindItems call? I'm experiencing some strange behaviour from EWS: http://stackoverflow.com/questions/28195941/ews-finditems-call-returns-incorrect-effectiverights-values
Matthias Leibmann
@mattleib
Note that EWS does support OAuth in Office 365, for both code and client-credential flow. The only difference to the Rest APIs is the permissions. EWS only supports "full access to mailbox" while Rest APIs do only support the granular permissions specific to a class of resources (Calendar, Mail, Contact). We recently updated the permission strings in the Application registration portal to better signal what is available for EWS. From a OAuth protocol point of view there is no difference. Note that maybe you had some issues in the preview phase where we marked the "full access to mailbox" permission as "admin only", meaning they required an admin to consent. With GA we removed this restriction. All permissions are now consent-able by an end-user. More here: https://msdn.microsoft.com/en-us/library/office/dn903761(v=exchg.150).aspx
Mike Noordermeer
@MikeN123
Thanks for the update. The client-credential flow seems to be a recent change we have been waiting for a long time ;-) I spotted your blog at http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx
Victor Boctor
@vboctor
I’ve created the wiki for the project. Feel free to start creating content or move content from the readme file to there.
Russell Bolles
@Helmsdown
Wanted to confirm that a snapshot build has not been published to https://oss.sonatype.org/content/repositories/snapshots
Victor Boctor
@vboctor
Victor Boctor
@vboctor
Any suggestions on the rhythm of pushing the snapshot package out? Should we do this manually weekly + ondemand when there is a critical bug?
Or should we integrate with Travis or do some continuous integration setup? If so, any suggestions taking into consideration that the sonatype password should be secure.
For example, I can probably setup Jenkins and make it do the work, but I wonder if there is a better/lighter weight option.
Asbjørn Aarrestad
@ahaarrestad
great that the api has been pushed to sonatype :-) regarding the question on when to push snapshots, my questions in return is what others do.
we don't need to push weekly if nobody's been changing it.
and to push each time we merge is perhaps a bit too often?
Asbjørn Aarrestad
@ahaarrestad
Asking around today I got a couple of good replies...
  1. push a snapshot whenever you've finished something.
  2. try to release often!
Pathikrit Bhowmick
@pathikrit
I think snapshots should be pushed on every succesful travis build as an after_success hook. See this: https://gist.github.com/neothemachine/4060735
Releases can be manual step
You can store encrypted passwords on travis just fine
Asbjørn Aarrestad
@ahaarrestad
I agree on the "push-pr-merge" when we have a stable release to rely on, but perhaps we should have a bit more restricted push-policy until then?
André Behrens
@serious6
I would also suggest in autodeploying snapshots to the maven snapshot repo. The following needs to be handled when we try to do that:
  • username and password should be encrypted (even if this sounds like an easy step for travis maybe it could be usefull to create another jira-account (@ossrh) which only has privileges to deploy to the snapshot repo)
  • deployment should only be done by one of the 3 builds and only if all verification is successful
  • KISS (keep it simple and stupid)
@pathikrit the mentioned python-script looks a little stuffed. Maybe there is a more lightweight alternative
@ahaarrestad dont think push-policy should be restricted since a snapshot release will always be a snapshot and not a stable one
jvh003
@jvh003
Hi... just getting started here.
Wondering what happened to 1.3? Was it ever released (ie: maven released) ? or is the 2.0-snapshot the only available version in sonatype.org ?
If the answer is yes... do you know when 2.0 will be released?
Would be nice to have a stable/released version to base my app. on.
André Behrens
@serious6
We are currently planing the 2.0 release milestone. Therefore everybody is invited to declare issues that need to be fixed before the deployment is done. Maybe for not breaking packages again a restructuring of the classes in packages and subpage would be useful. This could be handled like it is in the ews-managed-api.
André Behrens
@serious6
while thinking on that package restructuring I would suggest in not doing this with the 2.0 release since this would force every user to update their imports which could be dangerous if people just change maven dependency from snapshot to stable. Maybe we can include these restructuring into another major release. I think this would make live easier.
Stefan Gantner
@gantners
Can anybody tell me if the old timezone setting problem from ews 1.2 has been fixed already?
Mike Noordermeer
@MikeN123
Dunno what specific problem you are referring to, but there have been tons of timezone/data parsing fixes, like OfficeDev/ews-java-api#6
Stefan Gantner
@gantners
Mike Noordermeer
@MikeN123
You can just use UTC, the date and time will be shown in the user's timezone anyway.
jvh003
@jvh003
Thanks for the response on 2.0. Agree that re-org on imports type of change would be nicer in next version.
So what about 1.3? Seems it never did get released?
Mike Noordermeer
@MikeN123
Nope, and 1.4, 1.5, 1.6, 1.7 etc. weren't released either ;)
Pathikrit Bhowmick
@pathikrit
for that matter 2.0 wasn't released either. only snapshots are available.
jvh003
@jvh003
Have noticed something a little strange with getUserAvailability(). Testing with exchange 2010 server.
It seems that the TimeWindow start & end should be set in UTC, but the calendar events (CalendarEvent)
coming back (ie: start & end times) are in local time.
Is this correct?
or am I missing something here?
( I was comparing to the 1.1.5 version of this pkg, where all times send & rec'd were in UTC ).
jvh003
@jvh003
( oops... for 1.1.5 version... only times rec'd in UTC, not sent )