| Time |
S |
Nick |
Message |
| 00:43 |
|
|
eschmidbauer joined #rest |
| 00:44 |
|
|
shrink0r_ joined #rest |
| 00:56 |
|
|
huckleberry78 joined #rest |
| 01:06 |
|
|
pindonga joined #rest |
| 01:09 |
|
|
rosstuck joined #rest |
| 02:44 |
|
|
lemur joined #rest |
| 03:10 |
|
|
_ollie1 joined #rest |
| 04:49 |
|
|
ramsey joined #rest |
| 04:49 |
|
|
lebster joined #rest |
| 04:51 |
|
|
ekroon joined #rest |
| 04:53 |
|
|
imanc_ joined #rest |
| 05:09 |
|
|
tr3online joined #rest |
| 05:28 |
|
|
tr3online joined #rest |
| 06:10 |
|
|
csgeek joined #rest |
| 08:22 |
|
|
aGHz joined #rest |
| 09:08 |
|
|
Left_Turn joined #rest |
| 09:10 |
|
|
_ollie joined #rest |
| 09:11 |
|
|
quimrstorres joined #rest |
| 11:31 |
|
|
shrink0r joined #rest |
| 11:42 |
|
|
leo-unglaub joined #rest |
| 11:43 |
|
leo-unglaub |
hey guys, can someone please show me a way of implementing DELETE correctly without violationg it beeing idempotent? |
| 11:46 |
|
pdurbin |
once you delete something it's gone and you can't delete it again |
| 11:46 |
|
pdurbin |
I guess I don't understand what the question is. |
| 11:48 |
|
leo-unglaub |
pdurbin, well, calling DELETE /user/122344 twice is not possible |
| 11:48 |
|
leo-unglaub |
witch makes sence |
| 11:48 |
|
leo-unglaub |
however as far as i understand HTTP the DELETE operation must always return the same status |
| 11:48 |
|
leo-unglaub |
but that would not be correct |
| 11:53 |
|
asdf` |
leo-unglaub, idempotency means the effect on the resource of several request is the same as the effect of a single request |
| 11:53 |
|
asdf` |
the response can still be different, each request can be logged separately, etc |
| 11:55 |
|
leo-unglaub |
hmmm, asdf` your statement sounds way different than for example this here: http://www.restapitutorial.com/lessons/httpmethods.html -> down at the site bottom the DELETE tab |
| 11:55 |
|
pdurbin |
"the next time you call it you get a 404" -- whartung http://irclog.greptilian.com/rest/2015-03-10#i_101478 |
| 11:57 |
|
asdf` |
leo-unglaub, seems they use some other definition of idempotency, then! here's the rfc7231 one: https://tools.ietf.org/html/rfc7231#section-4.2.2 |
| 11:57 |
|
pdurbin |
asdf`: you trust the RFCs? ;) |
| 11:58 |
|
asdf` |
should i have checked the webster dictionary instead :p |
| 11:59 |
|
leo-unglaub |
asdf`, hmmm, very strange that they have two different definitions of it *g* |
| 12:03 |
|
pdurbin |
leo-unglaub: that tutorial you linked to says "POST, GET, PUT, and DELETE. These correspond to create, read, update, and delete (or CRUD)" |
| 12:03 |
|
pdurbin |
but that's a simplification |
| 12:04 |
|
pdurbin |
"such a trivial mapping is inaccurate at best" https://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/ |
| 12:09 |
|
leo-unglaub |
pdurbin, more to the point my problem is thw following: I am using the Hiawatha Webserver for all my stuff and i really like it. However the author of the webserver has a strong point on PUT and DELETE: https://www.hiawatha-webserver.org/forum/topic/245 |
| 12:09 |
|
leo-unglaub |
so i am currently not sure about how to do it the right way |
| 12:12 |
|
pdurbin |
I don't get what the strong point is from a quick look at that. |
| 12:13 |
|
pdurbin |
leo-unglaub: sum it up for us, if you feel like it |
| 12:14 |
|
leo-unglaub |
the basic problem is that the webserver does not pass a DELETE /user/12314 request on to a CGI appliccation |
| 12:14 |
|
leo-unglaub |
that makes it very hard to delete a resource restfull |
| 12:15 |
|
asdf` |
what does it do instead? remove the cgi script from the filesystem? |
| 12:15 |
|
leo-unglaub |
it returns 501 |
| 12:16 |
|
leo-unglaub |
and his reason for it is in the forum post i linked before |
| 12:17 |
|
pdurbin |
asdf`: that would be better than this: https://bugzilla.redhat.com/show_bug.cgi?id=1202858 :) |
| 12:18 |
|
pdurbin |
leo-unglaub: why does it return a 501? |
| 12:18 |
|
leo-unglaub |
thats what i am trying to figure out |
| 12:19 |
|
pdurbin |
"501 Not Implemented The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API)." |
| 12:25 |
|
pdurbin |
that post talks about rewriting |
| 12:30 |
|
|
quimrstorres joined #rest |
| 12:41 |
|
|
lemur joined #rest |
| 13:15 |
|
|
vanHoesel joined #rest |
| 13:17 |
|
|
shrink0r joined #rest |
| 13:40 |
|
|
graste joined #rest |
| 14:05 |
|
|
dEPy joined #rest |
| 14:10 |
|
|
shrink0r joined #rest |
| 14:19 |
|
|
rosstuck joined #rest |
| 14:19 |
|
|
quimrstorres joined #rest |
| 14:31 |
|
pdurbin |
whartung: you around? thinking about SAML and REST |
| 14:37 |
|
trygvis |
evenin' |
| 14:38 |
|
trygvis |
410 is a useful status code when using DELETE: http://httpstatus.es/410 |
| 14:38 |
|
pdurbin |
trygvis: I'd love to rope you into this too, but let's wait for whartung |
| 14:39 |
|
trygvis |
I guess it's hard to use if you actually delete data, but we never delete stuff, just mark them as deleted so we can support 410 |
| 14:41 |
|
|
quimrstorres joined #rest |
| 15:28 |
|
trygvis |
http://tools.ietf.org/html/rfc7511 |
| 15:34 |
|
asdf` |
needs infrastructure of hot air balloons and pigeons |
| 16:07 |
|
|
quimrstorres joined #rest |
| 16:13 |
|
trygvis |
it would be funny to rot13 all rels |
| 16:13 |
|
trygvis |
and path parts of the URIs |
| 16:13 |
|
trygvis |
that should keep people from looking at their values! |
| 16:30 |
|
whartung |
hey pdurbin trygvis |
| 16:31 |
|
|
hackel joined #rest |
| 16:40 |
|
trygvis |
hei! |
| 17:00 |
|
pdurbin |
whartung and trygvis: what do you think of this post I made this morning? http://shibboleth.1660669.n2.nabble.com/Shibboleth-authentication-to-a-RESTful-API-from-mobile-curl-etc-td7613455.html |
| 17:09 |
|
pdurbin |
trygvis: on a related note, I'm still hoping you can send me a link to code that lets you auth to google from android: http://irclog.greptilian.com/rest/2015-03-20#i_103683 :) |
| 17:11 |
|
whartung |
love to see that as a activity diagram pdurbin -- just not quite sure what is going on here. |
| 17:11 |
|
pdurbin |
whartung: well, do you see the curl command? |
| 17:11 |
|
pdurbin |
https://apitest.dataverse.org/api/v1/builtin-users/spruce/api-token?password=spruce |
| 17:12 |
|
whartung |
I was reading the ecp spec |
| 17:12 |
|
whartung |
"spec" |
| 17:12 |
|
pdurbin |
oh |
| 17:12 |
|
pdurbin |
yeah that's all new to me. that ECP thing |
| 17:13 |
|
whartung |
yea, I've seen it before I think |
| 17:13 |
|
whartung |
our use cases have been cetnered on transfer of authentication from a fat app to the web. |
| 17:15 |
|
whartung |
since most fat apps in fact talk to a server, we have the fat app make a request to the back end, the back end sends a signed AuthnRequest (I think) to us, and we return a token. Back end returns the token to the app, app launches a url with the token, destiantion web app verifies the token with us, and then logs them in |
| 17:18 |
|
whartung |
whenver I looked at SSO for fat apps, I always considered Kerberos |
| 17:19 |
|
pdurbin |
Is mobile so different? My little Android app talks to my server over REST. |
| 17:20 |
|
whartung |
but you're just looking for Share Credential, not so much SSO, right? |
| 17:20 |
|
whartung |
or do you want SSO with a web app that mobile launches? |
| 17:21 |
|
|
vipkilla joined #rest |
| 17:21 |
|
pdurbin |
so I want my Android app to prompt for a username and password |
| 17:22 |
|
pdurbin |
and to prompt for if they have a local account or a Shibboleth account |
| 17:23 |
|
pdurbin |
if they have a local account, the creditials will be sent to the server which will look up their API token and send that token back to the Android app |
| 17:23 |
|
pdurbin |
the Android app will squirrel away that API token and use it over and over for subsequent requests |
| 17:23 |
|
pdurbin |
should be easy enough for those non-Shibboleth users |
| 17:24 |
|
pdurbin |
since I can verify on my server if they have sent a valid username/password combination |
| 17:25 |
|
pdurbin |
I mean, I could even have the app create an account for them if they don't have one. A non-Shibboleth account. |
| 17:25 |
|
pdurbin |
am I making sense? |
| 17:26 |
|
whartung |
sec |
| 17:33 |
|
whartung |
what you really need |
| 17:33 |
|
whartung |
is an STS |
| 17:34 |
|
whartung |
I dont know is Shib is an STS |
| 17:34 |
|
whartung |
*if |
| 17:36 |
|
whartung |
I guess not |
| 17:36 |
|
whartung |
(at least as of 2011 |
| 17:36 |
|
pdurbin |
STS? |
| 17:36 |
|
whartung |
Secure Token Service |
| 17:36 |
|
pdurbin |
never heard of it but ok |
| 17:37 |
|
whartung |
http://en.wikipedia.org/wiki/Security_token_service |
| 17:38 |
|
whartung |
funny, I think netbeans has an STS project that makes one for glassfish |
| 17:38 |
|
whartung |
it's kind of opaque though |
| 17:38 |
|
whartung |
typically it's used in WSS-* stuff |
| 17:39 |
|
whartung |
http://owulff.blogspot.com/2012/02/saml-tokens-and-ws-trust-security-token.html |
| 17:39 |
|
whartung |
basically it formalizes the ideas of requesting a token and of vetting the token |
| 17:40 |
|
whartung |
in essense |
| 17:40 |
|
whartung |
the service needs only trust it's local server (doesn't need to trust the idp per se). |
| 17:40 |
|
whartung |
it asks it's local server to validate the token, the local server can then defer authentication via the chain of trust to the original IdP |
| 17:41 |
|
whartung |
in the end the IdP doesn't need to trust the service (directly) and vice-a-versa |
| 17:41 |
|
whartung |
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf |
| 17:42 |
|
pdurbin |
hmm. this is getting complicated |
| 17:42 |
|
whartung |
well, yea, the genearl standards usually are. |
| 17:42 |
|
whartung |
even the simple use cases in saml are complicated :D |
| 17:42 |
|
pdurbin |
:) |
| 17:43 |
|
whartung |
also |
| 17:43 |
|
whartung |
afaik |
| 17:43 |
|
whartung |
there's no way to simply "authenticate" with shiboleth |
| 17:43 |
|
whartung |
not the way it's wired |
| 17:43 |
|
whartung |
now, that's said, you can implement your own login modules with shib |
| 17:43 |
|
whartung |
and they can do whatever you want |
| 17:44 |
|
whartung |
including inpects the request that originally hits the login module |
| 17:44 |
|
pdurbin |
you mean that you first have to exchange metadata between the Service Provider (SP) and the Identity Provider (IdP) for Shibboleth users to authenticate |
| 17:44 |
|
whartung |
so, you could put the username/password in to the original request and the login module can then authenticate it |
| 17:45 |
|
whartung |
yea, you can't have a blind idp and a blind SP, right? they have to know about each other |
| 17:45 |
|
pdurbin |
right. they have to set up a trust first |
| 17:45 |
|
pdurbin |
it's built for institutions |
| 17:45 |
|
whartung |
(which is interesting in that with STS that's not the case -- the trust can be indirect) |
| 17:45 |
|
pdurbin |
so very unlike OAuth |
| 17:45 |
|
whartung |
right |
| 17:45 |
|
whartung |
OAuth is a different use case |
| 17:46 |
|
pdurbin |
OAuth puts the decision to trust in the hands of the end user, not an institution |
| 17:46 |
|
whartung |
no, you stil have to have the apps configured |
| 17:46 |
|
whartung |
it's not like OpenID was. |
| 17:46 |
|
pdurbin |
well, sure |
| 17:46 |
|
whartung |
openId would take trust implicitly from "anyone" |
| 17:46 |
|
whartung |
Oauth won't |
| 17:46 |
|
whartung |
(I don't think) |
| 17:46 |
|
pdurbin |
but the popular OAuth providers will let you set up the trust with no questions asked |
| 17:46 |
|
whartung |
it needs to swap a shared secret with the authority, right? |
| 17:47 |
|
whartung |
but that's a detail |
| 17:47 |
|
whartung |
as I understood openid, even that wasn't the case |
| 17:47 |
|
pdurbin |
in the Shibboleth world you have to exchange metadata directly (out of band) or join a common "federation" |
| 17:47 |
|
|
t_dot_zilla joined #rest |
| 17:47 |
|
whartung |
but that's the same thing you're doing with the oauth stuff -- sharaing meta data directly |
| 17:48 |
|
|
tr3online joined #rest |
| 17:48 |
|
whartung |
OpenId as I understood it WAS blind |
| 17:48 |
|
whartung |
they'd let anyone in. |
| 17:48 |
|
pdurbin |
but I don't have to ask Twitter or GitHub for permission |
| 17:48 |
|
whartung |
because they just wanted an identiy |
| 17:48 |
|
|
t_dot_zilla joined #rest |
| 17:48 |
|
whartung |
I mean, my knowledge may well be old. Oauth 2 is different from 1. |
| 17:49 |
|
pdurbin |
Twitter and GitHub will just give my application a secret oauth key or whatever |
| 17:49 |
|
pdurbin |
I don't have to fill out any paperwork |
| 17:49 |
|
whartung |
sure, but that's not what I mean |
| 17:49 |
|
pdurbin |
ok |
| 17:49 |
|
whartung |
you could easily create a web portal to open up a Shib server as wide as you wanted, right? |
| 17:49 |
|
pdurbin |
uh |
| 17:50 |
|
pdurbin |
not sure what you mean |
| 17:50 |
|
* pdurbin |
puts his black hat on |
| 17:50 |
|
whartung |
you're caught up on the exchange of meta data. |
| 17:50 |
|
whartung |
github is simply making that exchange easy |
| 17:50 |
|
pdurbin |
yeah |
| 17:50 |
|
whartung |
but the exchange still has to happen |
| 17:50 |
|
pdurbin |
sure |
| 17:50 |
|
whartung |
you could make the exchange for Shib "easy" if you wrote the proper interface |
| 17:51 |
|
whartung |
but in contrast |
| 17:51 |
|
pdurbin |
and of course github will block my app if it turns malicious |
| 17:51 |
|
whartung |
the original OpenID had implcit trust |
| 17:51 |
|
whartung |
For example, I could have created my own OpenID server, and used it to log into Stack Overflow -- they didn't care. |
| 17:51 |
|
pdurbin |
ok sure |
| 17:52 |
|
pdurbin |
I stood up my own openid server once. |
| 17:52 |
|
pdurbin |
there was a little php script for it |
| 17:52 |
|
whartung |
and that works for them, becuase if I use OpenID X and OpenID Y to log in to SO, I'd get to identities. But SO would later let me merge them. |
| 17:52 |
|
whartung |
because in the end, SO managed it's own internal entities, but just didn't manage the passwords |
| 17:53 |
|
pdurbin |
well |
| 17:53 |
|
whartung |
and SO is the ilk that really doesn't care who I am, because, as you said, they can always ban a malicious user no matter how they authenticate |
| 17:53 |
|
whartung |
and OpenID doesn't offer authorization |
| 17:53 |
|
whartung |
(or if it did, no one would trust it anyway lol) |
| 17:53 |
|
pdurbin |
stackoverflow allows you to log in to the same account by multiple means. various identity providers. I like this a lot a lot. |
| 17:53 |
|
whartung |
correct |
| 17:54 |
|
whartung |
Open ID I guess is falling by the wayside. |
| 17:54 |
|
whartung |
Google is turning theirs off in a couple of months |
| 17:54 |
|
pdurbin |
it means if I lose access to one of those identity providers I can just log in with a different one (and delete the one I can't use any more) |
| 17:54 |
|
whartung |
correct |
| 17:55 |
|
whartung |
I used to log in to so with blogger, but I moved it to gmail (same thing, but it doesn't know that, and blogger stopped working( |
| 17:55 |
|
whartung |
I should find another provider |
| 17:55 |
|
whartung |
if google is turning there's off |
| 17:55 |
|
pdurbin |
right. i used blogger too |
| 17:55 |
|
whartung |
I don't know if SO is going to migrate or not, I havent heard anything |
| 17:55 |
|
whartung |
but now |
| 17:55 |
|
whartung |
OpenID 2 (or whatever it is) is conflated with OAuth |
| 17:56 |
|
pdurbin |
hmm, I'm only using blogger and google. I guess I should add another (for my stackoverflow account) |
| 17:57 |
|
pdurbin |
and you seem to be saying auth via google is going away |
| 17:58 |
|
whartung |
loging in to so with google just now, Ididn't get a warning that it was going away |
| 17:58 |
|
whartung |
so so may have swtiched over |
| 17:58 |
|
pdurbin |
ok. that would make sense |
| 17:58 |
|
pdurbin |
they've said most people use google to log in |
| 17:59 |
|
whartung |
this is waht I recall |
| 17:59 |
|
whartung |
https://developers.google.com/accounts/docs/OpenID2 |
| 18:00 |
|
whartung |
this is what they changed to |
| 18:00 |
|
whartung |
https://developers.google.com/accounts/docs/OpenIDConnect |
| 18:00 |
|
whartung |
"OpenID Connect" (which is oauth 2.0) |
| 18:00 |
|
whartung |
That's not confusing! |
| 18:01 |
|
pdurbin |
heh |
| 18:01 |
|
pdurbin |
less confusing than SAML though |
| 18:01 |
|
saml |
yah i confuse |
| 18:02 |
|
whartung |
well the prblem with saml is that a) he's a wiseguy, b) web sso profile is the dominant use case c) it has all the boiler plate for federation that most SSO don't need. |
| 18:03 |
|
saml |
i SSO max |
| 18:03 |
|
saml |
i thought it was seo |
| 18:03 |
|
saml |
oh single sign on |
| 18:03 |
|
whartung |
I thought it was eieio |
| 18:04 |
|
|
vanHoesel joined #rest |
| 18:04 |
|
pdurbin |
we actually do want the federation stuff, I guess. it would be nice to allow ~400 institutions to log int our app |
| 18:04 |
|
whartung |
you bet |
| 18:05 |
|
pdurbin |
so i continue to make peace with saml |
| 18:05 |
|
pdurbin |
but I don't feel like I'm any closer to a solution for that Android app |
| 18:06 |
|
whartung |
isnt' there some kind of semi-official higher-ed federation ? |
| 18:06 |
|
pdurbin |
in the US, yes. incommon |
| 18:06 |
|
whartung |
is that a big saml metadata soup thing? |
| 18:06 |
|
pdurbin |
huh. where's searchbot |
| 18:07 |
|
pdurbin |
InCommon: Security, Privacy and Trust for the Research and Education Community - http://www.incommon.org |
| 18:07 |
|
pdurbin |
fairly official, I'd say |
| 18:07 |
|
pdurbin |
not sure what there is for other countries |
| 18:08 |
|
whartung |
yea, see the problem there |
| 18:08 |
|
whartung |
with taht system |
| 18:08 |
|
whartung |
if I wanted to log in to your app |
| 18:08 |
|
whartung |
I'd inevitably get to a login page at my university |
| 18:08 |
|
pdurbin |
sure |
| 18:09 |
|
pdurbin |
that's not a problem. that's the goal |
| 18:09 |
|
whartung |
but with mobile there's not way right now, using saml that I know of, to direct a off line gathered credential to the appropriate authority |
| 18:09 |
|
whartung |
how is the idp selected? |
| 18:09 |
|
pdurbin |
well, see the thread I started |
| 18:09 |
|
whartung |
do you just have a list of idps on your login page? |
| 18:10 |
|
pdurbin |
"Most uses tend to be single-IdP and so things get baked in. There's not much state of art in handling multiple IdPs or how to make sure they can be trusted (i.e., commercial TLS is broken, so relying on that is a disservice to all of your users)." |
| 18:10 |
|
pdurbin |
http://shibboleth.1660669.n2.nabble.com/Shibboleth-authentication-to-a-RESTful-API-from-mobile-curl-etc-td7613455.html |
| 18:10 |
|
pdurbin |
but really, I *would* be interested in multiple IdPs. those ~400 IdPs |
| 18:11 |
|
whartung |
well the other problem with collecting the credentail at the client |
| 18:11 |
|
whartung |
is you can't handle 2 factor scenarios |
| 18:12 |
|
whartung |
when you delegate teh login experience to the 3rd party they can do whatever they want |
| 18:12 |
|
whartung |
name, password, capthca, 2 factor, etc. |
| 18:12 |
|
whartung |
that's easy on the web as it can delgate user experience as well "click on the bouncing ball to log in" |
| 18:12 |
|
pdurbin |
good point about 2 factor |
| 18:13 |
|
whartung |
that's not possible (easily) with a native login |
| 18:13 |
|
pdurbin |
oh, two days ago I heard Gillette announce *three* factor authentication |
| 18:13 |
|
whartung |
do you know how to launch a browser and get a credential out of it? like get the cookie or something? |
| 18:13 |
|
whartung |
o rly? |
| 18:14 |
|
pdurbin |
from android? buh. I don't know. I guess I was hoping to not launch a browser. but it seems to be the shibboleth way |
| 18:15 |
|
whartung |
well I'm curious how it works |
| 18:15 |
|
whartung |
I mean, ok, yea, you get in to the login page at shib |
| 18:15 |
|
whartung |
but how does the app get a credential out of the browser to send up to the server on it's own channel? |
| 18:16 |
|
* pdurbin |
thinks |
| 18:16 |
|
pdurbin |
I'm not sure. I'd rather not do this in the browser. |
| 18:17 |
|
whartung |
of courese, extra amusing with 2 factor, is many folks are using the mobile AS the second factor. |
| 18:17 |
|
whartung |
which makes it kind of moot for a mobile app lol |
| 18:17 |
|
pdurbin |
heh. sure |
| 18:17 |
|
whartung |
what did Gilette do? |
| 18:18 |
|
pdurbin |
:) |
| 18:18 |
|
pdurbin |
two days ago... |
| 18:19 |
|
whartung |
I'm curious why scott says that commercial TLS is broken |
| 18:19 |
|
pdurbin |
whartung: you should join the list! |
| 18:19 |
|
pdurbin |
I'm always making a fool of myself there. |
| 18:19 |
|
whartung |
Oh, I'm on sib users - I just don't read it |
| 18:19 |
|
pdurbin |
and here |
| 18:20 |
|
pdurbin |
I read some of it. |
| 18:20 |
|
whartung |
https://www.dropbox.com/s/9inwyoiefm7mtb0/Screenshot%202015-04-03%2011.20.04.png?dl=0 |
| 18:20 |
|
pdurbin |
whartung: nice! jump in there! the fray! |
| 18:22 |
|
whartung |
huh what's this "OAuth SAML Bearer" |
| 18:23 |
|
pdurbin |
maybe he has bad news |
| 18:23 |
|
whartung |
unforunately, Shib User is where I learned to hate Shib lol |
| 18:23 |
|
whartung |
Scott simply assumes you've read every oasis spec and rfc germane to your use case and doesn't explain anything lol |
| 18:24 |
|
pdurbin |
he's helping |
| 18:24 |
|
pdurbin |
I appreciate the help. |
| 18:25 |
|
pdurbin |
seems like a good guy |
| 18:25 |
|
whartung |
oh the help is there, it's just for me it was like pulling teeth |
| 18:25 |
|
pdurbin |
things got better when I started using their software |
| 18:26 |
|
whartung |
what token were you thinkig of copying/pasting? |
| 18:28 |
|
pdurbin |
the user's API token, which we are now exposing if you provide your username and password: https://apitest.dataverse.org/api/v1/builtin-users/spruce/api-token?password=spruce |
| 18:29 |
|
pdurbin |
but we can only verify your username and password if you're a non-Shibboleth user, a local/builtin user |
| 18:29 |
|
whartung |
ok |
| 18:29 |
|
whartung |
right |
| 18:30 |
|
pdurbin |
so for non-Shibboleth users, it's a simple matter of programming to get the user's API token into the Andoird app |
| 18:30 |
|
whartung |
right |
| 18:32 |
|
whartung |
I wrote scott off line about his tls comment |
| 18:33 |
|
pdurbin |
ok |
| 18:34 |
|
whartung |
so I asked my friend, who's an iOS guru |
| 18:34 |
|
whartung |
I don't know anything about android, but "anything iOS can do, android can do better" or something.... |
| 18:34 |
|
whartung |
anyay |
| 18:34 |
|
whartung |
one technique |
| 18:34 |
|
whartung |
is in iOS |
| 18:34 |
|
whartung |
you can create web view |
| 18:34 |
|
whartung |
and it can have a delegate |
| 18:35 |
|
whartung |
each time the page changes, the redirect is called |
| 18:35 |
|
whartung |
so can open a web view to hit your main landing page |
| 18:35 |
|
whartung |
the landing page goes through normal sso |
| 18:35 |
|
whartung |
and redirects you to the idp |
| 18:35 |
|
whartung |
idp authenticates and sends you back to the app |
| 18:35 |
|
whartung |
app bounces around and takes you to the landing page |
| 18:36 |
|
whartung |
the app can watch this |
| 18:36 |
|
whartung |
and, for example, steal the session cookie from the app |
| 18:36 |
|
whartung |
and then use that for it's rest calls |
| 18:36 |
|
whartung |
(or some other token) |
| 18:36 |
|
whartung |
for example it can look for the "app_security_token" cookie, and when it sees that being set, it just steals it and closes the web view. |
| 18:36 |
|
pdurbin |
in our app the session only lasts until you close your browser |
| 18:37 |
|
pdurbin |
so I'd probably wan some other token. the API token, ideally, I guess |
| 18:37 |
|
whartung |
yea, just make it a first class concept |
| 18:37 |
|
whartung |
most web apps just rely on a session without exposing a first class token |
| 18:37 |
|
whartung |
but you can do that |
| 18:37 |
|
pdurbin |
stuff it into a cookie |
| 18:38 |
|
pdurbin |
then delete the cookie once i've persisted the API token into the Android app, I guess |
| 18:38 |
|
whartung |
just destroy the web view |
| 18:38 |
|
pdurbin |
sure |
| 18:39 |
|
whartung |
you can also use javascript injection and crap I guess |
| 18:39 |
|
whartung |
but something to consider |
| 18:39 |
|
pdurbin |
hehh |
| 18:39 |
|
pdurbin |
I mean, I haven't done any of this on Android, but it makes sense. |
| 18:40 |
|
pdurbin |
honestly, I'm thinking multiple auth would be better |
| 18:40 |
|
pdurbin |
like stackoverflow has |
| 18:41 |
|
whartung |
well that's just domain selection |
| 18:41 |
|
whartung |
we added multipler domains to our idp |
| 18:41 |
|
pdurbin |
that way the shib users could use some other auth to get their API token. they could also have a local username/password |
| 18:42 |
|
pdurbin |
but we took multiple auth out in a fit of merging and refactoring |
| 18:42 |
|
pdurbin |
:( |
| 18:42 |
|
pdurbin |
a murder of crows, a parliament of owls, a merge conflict of developers |
| 18:42 |
|
fumanchu |
:) |
| 18:43 |
|
whartung |
svn/git never forgets, never merges….:) |
| 18:44 |
|
pdurbin |
▶ Hitler uses git - YouTube - https://www.youtube.com/watch?v=CDeG4S-mJts |
| 18:46 |
|
whartung |
lol |
| 18:48 |
|
whartung |
"Do you listen to yourself? You don't even know WTF that means!" |
| 18:49 |
|
|
shrink0r joined #rest |
| 18:50 |
|
pdurbin |
heh |
| 18:55 |
|
|
shrink0r_ joined #rest |
| 19:01 |
|
|
hackel joined #rest |
| 19:38 |
|
|
quimrstorres joined #rest |
| 21:03 |
|
|
quimrstorres joined #rest |
| 21:23 |
|
|
vanHoesel joined #rest |
| 21:50 |
|
|
dreamdust left #rest |
| 22:07 |
|
|
quimrsto_ joined #rest |
| 22:24 |
|
|
mezod joined #rest |
| 22:28 |
|
|
quimrstorres joined #rest |
| 22:35 |
|
|
pezra joined #rest |
| 23:55 |
|
|
shrink0r joined #rest |
