| Time |
S |
Nick |
Message |
| 01:04 |
|
|
Andre-B joined #rest |
| 01:09 |
|
|
Left_Turn joined #rest |
| 01:15 |
|
|
shrink0r_ joined #rest |
| 02:33 |
|
|
shrink0r joined #rest |
| 03:10 |
|
|
lemur joined #rest |
| 03:11 |
|
|
lemur joined #rest |
| 03:46 |
|
|
shrink0r_ joined #rest |
| 03:51 |
|
|
shrink0r joined #rest |
| 03:51 |
|
|
tr3onlin_ joined #rest |
| 03:53 |
|
|
shrink0r_ joined #rest |
| 04:03 |
|
|
proteusguy joined #rest |
| 04:49 |
|
|
tr3online joined #rest |
| 05:12 |
|
|
PalyaPix joined #rest |
| 05:48 |
|
|
lemur joined #rest |
| 06:11 |
|
|
shrink0r joined #rest |
| 06:12 |
|
|
lemur joined #rest |
| 07:17 |
|
|
DrCode joined #rest |
| 08:00 |
|
|
shrink0r joined #rest |
| 08:06 |
|
|
DrCode joined #rest |
| 08:14 |
|
|
_ollie joined #rest |
| 08:30 |
|
|
lufi joined #rest |
| 08:30 |
|
|
lufi joined #rest |
| 08:32 |
|
lufi |
hi. in designing my api. should i send an error code for each error e.g. "username already exists" or "invalid username characters"? my current method is i set the status to 400 and include a "message" key in the json response that explains the error e.g. "USERNAME_EXISTS". |
| 08:42 |
|
trygvis |
sounds good |
| 08:47 |
|
|
lemur joined #rest |
| 08:50 |
|
|
mezod joined #rest |
| 09:01 |
|
|
lemur joined #rest |
| 09:05 |
|
|
rickardo1 joined #rest |
| 09:07 |
|
rickardo1 |
I need a client software for mac which have the ability to group and organize requests from different endpoints. I did try soapUi but think it's to blurry. Also tried the Advanced Rest Client plugin for Chrome but there is not good options for organizing requests. Any tips? |
| 09:08 |
|
lufi |
trygvis: what do you mean sounds good? |
| 09:14 |
|
trygvis |
lufi: your current way is the way I would do it |
| 09:20 |
|
|
DrCode joined #rest |
| 09:23 |
|
lufi |
the app devs are saying that using 'int' is "faster" than 'strings' .i really think its not that big of a deal dont you think? trygvis |
| 09:28 |
|
trygvis |
I would definitely use strings |
| 09:28 |
|
lufi |
hmm to be easily understood? |
| 09:29 |
|
trygvis |
yep |
| 09:36 |
|
|
lemur joined #rest |
| 09:38 |
|
|
DrCode joined #rest |
| 09:49 |
|
|
shrink0r joined #rest |
| 10:03 |
|
|
proteusguy joined #rest |
| 10:05 |
|
|
marcoslamuria joined #rest |
| 10:08 |
|
|
martinfilliau joined #rest |
| 10:36 |
|
|
proteusguy joined #rest |
| 10:37 |
|
|
Left_Turn joined #rest |
| 10:39 |
|
|
Andre-B joined #rest |
| 10:46 |
|
|
codeisgreat joined #rest |
| 11:04 |
|
|
DrCode joined #rest |
| 11:38 |
|
|
shrink0r joined #rest |
| 11:38 |
|
* blongden |
waves |
| 11:39 |
|
blongden |
Is JSON Home still application/json-home instead of what it should be (application/home+json)? |
| 11:39 |
|
blongden |
Because, :( |
| 11:46 |
|
|
_ollie joined #rest |
| 11:51 |
|
|
shrink0r joined #rest |
| 11:53 |
|
|
shrink0r_ joined #rest |
| 11:56 |
|
|
shrink0r joined #rest |
| 12:00 |
|
|
mezod joined #rest |
| 12:12 |
|
|
ramsey_ joined #rest |
| 12:42 |
|
|
_ollie joined #rest |
| 12:45 |
|
pdurbin |
whartung: by you: http://irclog.greptilian.com/sourcefu/2014-12-11#i_87454 :) |
| 12:52 |
|
trygvis |
I'm a big fan of flyway for sql migrations |
| 13:00 |
|
* pdurbin |
should try it |
| 13:08 |
|
|
shrink0r_ joined #rest |
| 13:10 |
|
|
nkoza joined #rest |
| 13:20 |
|
|
mezod joined #rest |
| 13:21 |
|
|
graste joined #rest |
| 13:30 |
|
|
_ollie joined #rest |
| 13:58 |
|
|
znn joined #rest |
| 14:08 |
|
|
mezod_ joined #rest |
| 14:20 |
|
|
shrink0r joined #rest |
| 14:48 |
|
|
marcoslamuria joined #rest |
| 15:06 |
|
|
Mxyzpltk joined #rest |
| 15:09 |
|
|
marcoslamuria joined #rest |
| 15:42 |
|
|
mezod joined #rest |
| 17:09 |
|
|
shrink0r joined #rest |
| 17:14 |
|
|
shrink0r_ joined #rest |
| 17:29 |
|
|
shrink0r joined #rest |
| 17:32 |
|
|
marcoslamuria joined #rest |
| 17:46 |
|
|
DacFarren joined #rest |
| 17:49 |
|
DacFarren |
Hey... is there any info about secure rest apis?,.. trying to find some info on the groups, without success yet.... |
| 17:52 |
|
pdurbin |
DacFarren: use HTTPS |
| 17:56 |
|
trygvis |
DacFarren: yeah, and define 'secure' |
| 18:06 |
|
|
mezod joined #rest |
| 18:08 |
|
|
_ollie joined #rest |
| 18:22 |
|
|
proteusguy joined #rest |
| 18:28 |
|
|
znn joined #rest |
| 18:31 |
|
DacFarren |
Hey sorry the delay , so Im trying to send some sensitive data over a request to a rest api (user/pass, etc) and I need to use some secure way to encrypt and validate that info |
| 18:32 |
|
DacFarren |
I have been reading a lot of HMAC, but i havent find yet a proper document on how to implement this |
| 18:33 |
|
DacFarren |
on the other hand theres lot of documentation on securing rest apis with oauth, but I think the complexity this provides makes it worthless |
| 18:39 |
|
trygvis |
sounds like a case where HTTPS covers it |
| 18:50 |
|
|
sulky joined #rest |
| 18:51 |
|
DacFarren |
thanks trygvis ... in which cases would you consider a good solution signing request |
| 18:51 |
|
DacFarren |
like amazon does |
| 18:56 |
|
|
tr3online joined #rest |
| 18:59 |
|
|
sulky_ joined #rest |
| 19:01 |
|
whartung |
simply put, you have to ask a single question. |
| 19:01 |
|
whartung |
Either you trust HTTPS or you don't. If you do, then it's triviall: HTTP BASIC over HTTPS, and all of the work is punted to the transport layer. |
| 19:01 |
|
whartung |
Otherwise, you get to do all of the work youself. |
| 19:04 |
|
|
graste joined #rest |
| 19:04 |
|
DacFarren |
It could be a risk ... sending all that info over one request, even if we are talking on ssl |
| 19:07 |
|
whartung |
how so? |
| 19:07 |
|
whartung |
what does "all that info" have to do with it? |
| 19:15 |
|
gamache |
HTTPS just works, and if TLS handshakes are not a performance concern, it'd be silly to use anything else. |
| 19:15 |
|
gamache |
The handshaking can take annoyingly long on e.g. mobile, so sometimes a secure strategy over HTTP is needed, and that is what Amazon has. |
| 19:16 |
|
whartung |
I used to be an advocate of the AWS approach, but that only makes sense over HTTP. And even then, it doesn't protect the payload (well it does, from modifcation, but not viewing). But if you have HTTPS, then that all washes away -- just use BASIC. |
| 19:17 |
|
gamache |
the only reason to avoid HTTP Basic Auth is if your API also responds to unencrypted requests -- in this case it is possible for a client to send auth info by accident. The best approach is to not listen to unencrypted traffic; a compromise approach is to respond to unencrypted API calls with a 426 Upgrade Required status. |
| 19:17 |
|
whartung |
yup I'd be onboard with that. |
| 19:22 |
|
DacFarren |
that is great info, thanks a lot, mostly of the search results points to Oauth, i was struggling to find a more lighter design.. |
| 19:29 |
|
pdurbin |
DacFarren: how about API tokens, like GitHub has? |
| 19:30 |
|
whartung |
he said he wantd to encrypt the payload |
| 19:30 |
|
pdurbin |
hmm. ok |
| 19:34 |
|
DacFarren |
well I said that ... |
| 19:35 |
|
DacFarren |
but putting that aside, talking about Api Tokens that is Oauth right?, I believe I will be adding a lot of complexity to the implementation |
| 19:36 |
|
DacFarren |
or maybe not, havent got deeply into the oauth protocol |
| 19:37 |
|
whartung |
just because they have "Api Tokens" doesn't mean it has anything to do with OAuth (It may, I haven't looked at Git, I don't even know what "Api Tokens" empower you to do) |
| 19:37 |
|
whartung |
the nice thing about AWS |
| 19:37 |
|
whartung |
is that they cover, and document, and have code for (at least client side) the gamut of authentication scenarios. |
| 19:37 |
|
whartung |
From simple authentication, to leases, ACL, etc. |
| 19:38 |
|
whartung |
So it's a good One Stop Shopping for those facilities if that's something you need |
| 19:56 |
|
pdurbin |
we're using API tokens because we don't want people to send their actual passwords. the API tokens are more limited in what they let you do. you can't change your password with an API token, for example |
| 20:04 |
|
|
DacFarren joined #rest |
| 20:05 |
|
|
shrink0r joined #rest |
| 20:23 |
|
gamache |
DacFarren: Make sure you are looking at OAuth 2.0, not 1.x. 1.x makes a lot of funny decisions instead of making HTTPS mandatory. OAuth2 makes HTTPS the only acceptable transport, and simplifies the rest of the protocol quite a lot as a result. |
| 20:26 |
|
whartung |
…and if you're using HTTPS… :) |
| 20:26 |
|
whartung |
OAuth is good if yo uneed to federate and share trust. If not, it's overkill. |
| 20:28 |
|
gamache |
there are other reasons which make it attractive |
| 20:28 |
|
whartung |
such as |
| 20:29 |
|
gamache |
so for instance, I'd like to be able to hit my API server directly from the browser side of our front-end website. |
| 20:30 |
|
gamache |
either I need to invent a system where I exchange username and password for a short-lived access token, or I choose the one that other people invented and spent a lot more time on. |
| 20:30 |
|
whartung |
that's the "federation and share trust" thing I was talking about |
| 20:30 |
|
gamache |
I guess what I mean is that the Oauth 2.0 flows are basically the minimum viable flows to accomplish what they do |
| 20:31 |
|
gamache |
so if you are trying to accomplish one or more of them, might as well not fight it |
| 20:31 |
|
gamache |
that said, I was able to use HTTP Basic for almost two years before we started to really need something better |
| 20:32 |
|
|
shrink0r_ joined #rest |
| 20:38 |
|
|
jackalista joined #rest |
| 20:52 |
|
|
DacFarren joined #rest |
| 21:05 |
|
DacFarren |
we are looking into a api management in the future, often those software use oauth in their implementations, I believe it would be better to have a fast solution like http basic |
| 21:10 |
|
DacFarren |
gamache: Im curious about the complexity Oauth2 adds to the implementations |
| 21:11 |
|
DacFarren |
did you have to put a third party app to achieve sso ? |
| 21:28 |
|
gamache |
DacFarren: we're still implementing. short answer: A Lot |
| 21:28 |
|
gamache |
but anything but no auth is more complex than Basic Auth. |
| 21:28 |
|
|
marcoslamuria joined #rest |
| 21:43 |
|
whartung |
yea, exactly. BASIC is, well, really basic. |
| 21:43 |
|
whartung |
Ouath is orders of magnitude more complciated |
| 21:44 |
|
gamache |
we're starting out with a very simple authorization backend that our oauth server will hook into. this authz is based on our existing table of credentials |
| 21:44 |
|
whartung |
But I look at it this way. |
| 21:44 |
|
whartung |
for our stuff |
| 21:44 |
|
gamache |
once that is up and running and we're on oauth in a meaningful way, we're going to get into finer-grained authz |
| 21:44 |
|
whartung |
pre-rest, etc.just web app. |
| 21:45 |
|
whartung |
we started with simple password and HTTP sessions. |
| 21:45 |
|
whartung |
now we have all sorts of different mechanisms that we support, but the underlying code hasn't changed. |
| 21:46 |
|
gamache |
that's our goal as well |
| 21:46 |
|
whartung |
simply put, come up with some mechanism to get your security context set up, and then live off of that. Once you're there, HOW that context is stiood up becomes irrelevant to the code. |
| 21:47 |
|
whartung |
we have passwords against a db, passwords against ldap, SAML SSO, AWS token, SSL Mutual auth, 3rd party trust tokens. We have al ltaht now - and the code taht cares, really, hasn't changed |
| 21:47 |
|
saml |
i see |
| 21:48 |
|
whartung |
we could readily add OAuth if we had too |
| 21:48 |
|
whartung |
we haven't had the need yet though |
| 21:48 |
|
whartung |
a servlet filter is an amazing thing. |
| 22:11 |
|
|
Andre-B joined #rest |
| 22:48 |
|
|
acalbaza joined #rest |
| 22:48 |
|
|
marcoslamuria joined #rest |
| 23:14 |
|
|
shrink0r joined #rest |
| 23:16 |
|
|
shrink0r_ joined #rest |
