chrome/test/data/extensions/api_test/webrequest/test_auth_required.html - Issue 8015004: webRequest.onAuthRequired listeners can provide authentication credentials.

Side by Side Diff: chrome/test/data/extensions/api_test/webrequest/test_auth_required.html

Issue 8015004: webRequest.onAuthRequired listeners can provide authentication credentials. (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: Fix indent Created 9 years, 2 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch | Annotate | Revision Log

« chrome/test/data/extensions/api_test/webrequest/test_api.html ('K') | « chrome/test/data/extensions/api_test/webrequest/test_api.html ('k') | chrome/test/data/extensions/api_test/webrequest/test_complex.html » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 <script src="framework.js">
	battre 2011/10/10 13:47:03 as some tests are blocking, there is a certain cha as some tests are blocking, there is a certain chance that this will be flaky (test_blocking.html has been disabled for that reason). http://crbug.com/91715
	2 </script>

	3 <script>

	4 function getURLAuthRequired() {

	5 return getServerURL('auth-basic');

	6 }

	7

	8 runTests([

	9 // onAuthRequired is not a blocking function in this variant.

	10 function authRequiredNonBlocking() {

	11 expect(

	12 [ // events

	13 { label: "onBeforeRequest",

	14 event: "onBeforeRequest",

	15 details: {

	16 url: getURLAuthRequired(),

	17 frameUrl: getURLAuthRequired()

	18 }

	19 },

	20 { label: "onBeforeSendHeaders",

	21 event: "onBeforeSendHeaders",

	22 details: {

	23 url: getURLAuthRequired(),

	24 // Note: no requestHeaders because we don't ask for them.

	25 },

	26 },

	27 { label: "onSendHeaders",

	28 event: "onSendHeaders",

	29 details: {

	30 url: getURLAuthRequired(),

	31 }

	32 },

	33 { label: "onHeadersReceived",

	34 event: "onHeadersReceived",

	35 details: {

	36 url: getURLAuthRequired(),

	37 responseHeadersExist: true,

	38 statusLine: "HTTP/1.0 401 Unauthorized"

	39 }

	40 },

	41 { label: "onAuthRequired",

	42 event: "onAuthRequired",

	43 details: {

	44 url: getURLAuthRequired(),

	45 isProxy: false,

	46 scheme: "basic",

	47 realm: "testrealm",

	48 challenger: {host: testServer, port: testServerPort},

	49 responseHeadersExist: true,

	50 statusLine: "HTTP/1.0 401 Unauthorized",

	51 }

	52 },

	53 { label: "onResponseStarted",

	54 event: "onResponseStarted",

	55 details: {

	56 url: getURLAuthRequired(),

	57 fromCache: false,

	58 statusCode: 401,

	59 ip: "127.0.0.1",

	60 responseHeadersExist: true,

	61 statusLine: "HTTP/1.0 401 Unauthorized",

	62 }

	63 },

	64 { label: "onCompleted",

	65 event: "onCompleted",

	66 details: {

	67 url: getURLAuthRequired(),

	68 fromCache: false,

	69 statusCode: 401,

	70 ip: "127.0.0.1",

	71 responseHeadersExist: true,

	72 statusLine: "HTTP/1.0 401 Unauthorized",

	73 }

	74 },

	75 ],

	76 [ // event order

	77 ["onBeforeRequest", "onBeforeSendHeaders", "onSendHeaders",

	78 "onHeadersReceived", "onAuthRequired", "onResponseStarted",

	79 "onCompleted"]

	80 ],

	81 {}, ["responseHeaders"]);

	82 navigateAndWait(getURLAuthRequired());

	83 },

	84

	85 // onAuthRequired is a blocking function but takes no action in this variant.

	86 function authRequiredNoAction() {

	87 expect(

	88 [ // events

	89 { label: "onBeforeRequest",

	90 event: "onBeforeRequest",

	91 details: {

	92 url: getURLAuthRequired(),

	93 frameUrl: getURLAuthRequired()

	94 }

	95 },

	96 { label: "onBeforeSendHeaders",

	97 event: "onBeforeSendHeaders",

	98 details: {

	99 url: getURLAuthRequired(),

	100 // Note: no requestHeaders because we don't ask for them.

	101 },

	102 },

	103 { label: "onSendHeaders",

	104 event: "onSendHeaders",

	105 details: {

	106 url: getURLAuthRequired(),

	107 }

	108 },

	109 { label: "onHeadersReceived",

	110 event: "onHeadersReceived",

	111 details: {

	112 url: getURLAuthRequired(),

	113 responseHeadersExist: true,

	114 statusLine: "HTTP/1.0 401 Unauthorized"

	115 }

	116 },

	117 { label: "onAuthRequired",

	118 event: "onAuthRequired",

	119 details: {

	120 url: getURLAuthRequired(),

	121 isProxy: false,

	122 scheme: "basic",

	123 realm: "testrealm",

	124 challenger: {host: testServer, port: testServerPort},

	125 responseHeadersExist: true,

	126 statusLine: "HTTP/1.0 401 Unauthorized",

	127 }

	128 },

	129 { label: "onResponseStarted",

	130 event: "onResponseStarted",

	131 details: {

	132 url: getURLAuthRequired(),

	133 fromCache: false,

	134 statusCode: 401,

	135 ip: "127.0.0.1",

	136 responseHeadersExist: true,

	137 statusLine: "HTTP/1.0 401 Unauthorized",

	138 }

	139 },

	140 { label: "onCompleted",

	141 event: "onCompleted",

	142 details: {

	143 url: getURLAuthRequired(),

	144 fromCache: false,

	145 statusCode: 401,

	146 ip: "127.0.0.1",

	147 responseHeadersExist: true,

	148 statusLine: "HTTP/1.0 401 Unauthorized",

	149 }

	150 },

	151 ],

	152 [ // event order

	153 ["onBeforeRequest", "onBeforeSendHeaders", "onSendHeaders",

	154 "onHeadersReceived", "onAuthRequired", "onResponseStarted",

	155 "onCompleted"]

	156 ],

	157 {}, ["responseHeaders"]);
	battre 2011/10/10 13:47:03 forgot "blocking"? forgot "blocking"? cbentzel 2011/10/10 13:59:54 Oops! Thanks. Show quoted text On 2011/10/10 13:47:03, battre wrote: > forgot "blocking"? Oops! Thanks.
	158 navigateAndWait(getURLAuthRequired());

	159 },

	160

	161 // onAuthRequired is a blocking function that cancels the auth attempt.

	162 function authRequiredCancelAuth() {

	163 expect(

	164 [ // events

	165 { label: "onBeforeRequest",

	166 event: "onBeforeRequest",

	167 details: {

	168 url: getURLAuthRequired(),

	169 frameUrl: getURLAuthRequired()

	170 },

	171 retval: {}

	172 },

	173 { label: "onBeforeSendHeaders",

	174 event: "onBeforeSendHeaders",

	175 details: {

	176 url: getURLAuthRequired(),

	177 // Note: no requestHeaders because we don't ask for them.

	178 },

	179 retval: {}

	180 },

	181 { label: "onSendHeaders",

	182 event: "onSendHeaders",

	183 details: {

	184 url: getURLAuthRequired(),

	185 }

	186 },

	187 { label: "onHeadersReceived",

	188 event: "onHeadersReceived",

	189 details: {

	190 url: getURLAuthRequired(),

	191 responseHeadersExist: true,

	192 statusLine: "HTTP/1.0 401 Unauthorized"

	193 }

	194 },

	195 { label: "onAuthRequired",

	196 event: "onAuthRequired",

	197 details: {

	198 url: getURLAuthRequired(),

	199 isProxy: false,

	200 scheme: "basic",

	201 realm: "testrealm",

	202 challenger: {host: testServer, port: testServerPort},

	203 responseHeadersExist: true,

	204 statusLine: "HTTP/1.0 401 Unauthorized",

	205 },

	206 retval: {cancel: true}
	battre 2011/10/10 13:47:03 in all other handlers, {cancel: true} leads to "on in all other handlers, {cancel: true} leads to "onErrorOccurred". I am not sure whether we want to stick to this alternate meaning of "cancel". cbentzel 2011/10/10 13:59:54 Good question. I mentioned overloading "cancel" on Show quoted text On 2011/10/10 13:47:03, battre wrote: > in all other handlers, {cancel: true} leads to "onErrorOccurred". I am not sure > whether we want to stick to this alternate meaning of "cancel". Good question. I mentioned overloading "cancel" on an email thread and mpcomplete sounded OK with it, but I'm happy to change this. battre 2011/10/10 14:32:13 I guess I am OK with either approach. Show quoted text On 2011/10/10 13:59:54, cbentzel wrote: > On 2011/10/10 13:47:03, battre wrote: > > in all other handlers, {cancel: true} leads to "onErrorOccurred". I am not > sure > > whether we want to stick to this alternate meaning of "cancel". > > Good question. I mentioned overloading "cancel" on an email thread and > mpcomplete sounded OK with it, but I'm happy to change this. I guess I am OK with either approach.
	207 },

	208 { label: "onResponseStarted",

	209 event: "onResponseStarted",

	210 details: {

	211 url: getURLAuthRequired(),

	212 fromCache: false,

	213 statusCode: 401,

	214 ip: "127.0.0.1",

	215 responseHeadersExist: true,

	216 statusLine: "HTTP/1.0 401 Unauthorized",

	217 }

	218 },

	219 { label: "onCompleted",

	220 event: "onCompleted",

	221 details: {

	222 url: getURLAuthRequired(),

	223 fromCache: false,

	224 statusCode: 401,

	225 ip: "127.0.0.1",

	226 responseHeadersExist: true,

	227 statusLine: "HTTP/1.0 401 Unauthorized",

	228 }

	229 },

	230 ],

	231 [ // event order

	232 ["onBeforeRequest", "onBeforeSendHeaders", "onSendHeaders",

	233 "onHeadersReceived", "onAuthRequired", "onResponseStarted",

	234 "onCompleted"]

	235 ],

	236 {},

	237 ["responseHeaders", "blocking"]);

	238 navigateAndWait(getURLAuthRequired());

	239 },

	240

	241 // onAuthRequired is a blocking function that sets authentication credentials.

	242 // This needs to be done last, otherwise the authentication

	243 // credentials will be cached and the other tests will fail.

	244 function authRequiredSetAuth() {

	245 expect(

	246 [ // events

	247 { label: "onBeforeRequest",

	248 event: "onBeforeRequest",

	249 details: {

	250 url: getURLAuthRequired(),

	251 frameUrl: getURLAuthRequired()

	252 },

	253 retval: {}

	254 },

	255 { label: "onBeforeSendHeaders",

	256 event: "onBeforeSendHeaders",

	257 details: {

	258 url: getURLAuthRequired(),

	259 // Note: no requestHeaders because we don't ask for them.

	260 },

	261 retval: {}

	262 },

	263 { label: "onSendHeaders",

	264 event: "onSendHeaders",

	265 details: {

	266 url: getURLAuthRequired(),

	267 }

	268 },

	269 { label: "onHeadersReceived",

	270 event: "onHeadersReceived",

	271 details: {

	272 url: getURLAuthRequired(),

	273 responseHeadersExist: true,

	274 statusLine: "HTTP/1.0 401 Unauthorized"

	275 }

	276 },

	277 { label: "onAuthRequired",

	278 event: "onAuthRequired",

	279 details: {

	280 url: getURLAuthRequired(),

	281 isProxy: false,

	282 scheme: "basic",

	283 realm: "testrealm",

	284 challenger: {host: testServer, port: testServerPort},

	285 responseHeadersExist: true,

	286 statusLine: "HTTP/1.0 401 Unauthorized",

	287 },

	288 retval: {authCredentials: {username: "foo", password: "secret"}}
	battre 2011/10/10 13:47:03 we could add a test case where we specify the wron we could add a test case where we specify the wrong credentials. Are we asked again? What was the conclusion about the question how often an extension may try to submit credentials? cbentzel 2011/10/10 13:59:54 Yes, we're asked again. I'll add a test case. Show quoted text On 2011/10/10 13:47:03, battre wrote: > we could add a test case where we specify the wrong credentials. Are we asked > again? Yes, we're asked again. I'll add a test case. Show quoted text > > What was the conclusion about the question how often an extension may try to > submit credentials? I don't think there was consensus on what should happen in that case. One problem if we don't ask a second time is that the extension gets no signal that the provided credentials are bad. We could potentially add an onAuthFailed() handler to deal with this case, but that's actually a bit tricky since the authDetails are not guaranteed to be the same each round. battre 2011/10/10 14:32:13 How about adding a counter "authorizationAttempt"? Show quoted text On 2011/10/10 13:59:54, cbentzel wrote: > On 2011/10/10 13:47:03, battre wrote: > > we could add a test case where we specify the wrong credentials. Are we asked > > again? > > Yes, we're asked again. I'll add a test case. > > > > > What was the conclusion about the question how often an extension may try to > > submit credentials? > > I don't think there was consensus on what should happen in that case. > > One problem if we don't ask a second time is that the extension gets no signal > that the provided credentials are bad. We could potentially add an > onAuthFailed() handler to deal with this case, but that's actually a bit tricky > since the authDetails are not guaranteed to be the same each round. How about adding a counter "authorizationAttempt"? The extension author could use this to stop trying to log in after a number of attempts that are appropriate in his opinion. The author could track this number himself but this way, it might be more explicit that he is encouraged to think about the number of failures. cbentzel 2011/10/10 14:38:06 Arguably the extension author could maintain that Show quoted text On 2011/10/10 14:32:13, battre wrote: > On 2011/10/10 13:59:54, cbentzel wrote: > > On 2011/10/10 13:47:03, battre wrote: > > > we could add a test case where we specify the wrong credentials. Are we > asked > > > again? > > > > Yes, we're asked again. I'll add a test case. > > > > > > > > What was the conclusion about the question how often an extension may try to > > > submit credentials? > > > > I don't think there was consensus on what should happen in that case. > > > > One problem if we don't ask a second time is that the extension gets no signal > > that the provided credentials are bad. We could potentially add an > > onAuthFailed() handler to deal with this case, but that's actually a bit > tricky > > since the authDetails are not guaranteed to be the same each round. > > How about adding a counter "authorizationAttempt"? The extension author could > use this to stop trying to log in after a number of attempts that are > appropriate in his opinion. > > The author could track this number himself but this way, it might be more > explicit that he is encouraged to think about the number of failures. Arguably the extension author could maintain that count as well, using the details as a dictionary into a map. I'm always hesitant to add additional parameters to the API if not needed. battre 2011/10/10 14:47:10 Ok, but then we should highlight this problem in t Show quoted text On 2011/10/10 14:38:06, cbentzel wrote: > On 2011/10/10 14:32:13, battre wrote: > > On 2011/10/10 13:59:54, cbentzel wrote: > > > On 2011/10/10 13:47:03, battre wrote: > > > > we could add a test case where we specify the wrong credentials. Are we > > asked > > > > again? > > > > > > Yes, we're asked again. I'll add a test case. > > > > > > > > > > > What was the conclusion about the question how often an extension may try > to > > > > submit credentials? > > > > > > I don't think there was consensus on what should happen in that case. > > > > > > One problem if we don't ask a second time is that the extension gets no > signal > > > that the provided credentials are bad. We could potentially add an > > > onAuthFailed() handler to deal with this case, but that's actually a bit > > tricky > > > since the authDetails are not guaranteed to be the same each round. > > > > How about adding a counter "authorizationAttempt"? The extension author could > > use this to stop trying to log in after a number of attempts that are > > appropriate in his opinion. > > > > The author could track this number himself but this way, it might be more > > explicit that he is encouraged to think about the number of failures. > > Arguably the extension author could maintain that count as well, using the > details as a dictionary into a map. I'm always hesitant to add additional > parameters to the API if not needed. Ok, but then we should highlight this problem in the API documentation. cbentzel 2011/10/10 15:09:19 SGTM. Show quoted text On 2011/10/10 14:47:10, battre wrote: > On 2011/10/10 14:38:06, cbentzel wrote: > > On 2011/10/10 14:32:13, battre wrote: > > > On 2011/10/10 13:59:54, cbentzel wrote: > > > > On 2011/10/10 13:47:03, battre wrote: > > > > > we could add a test case where we specify the wrong credentials. Are we > > > asked > > > > > again? > > > > > > > > Yes, we're asked again. I'll add a test case. > > > > > > > > > > > > > > What was the conclusion about the question how often an extension may > try > > to > > > > > submit credentials? > > > > > > > > I don't think there was consensus on what should happen in that case. > > > > > > > > One problem if we don't ask a second time is that the extension gets no > > signal > > > > that the provided credentials are bad. We could potentially add an > > > > onAuthFailed() handler to deal with this case, but that's actually a bit > > > tricky > > > > since the authDetails are not guaranteed to be the same each round. > > > > > > How about adding a counter "authorizationAttempt"? The extension author > could > > > use this to stop trying to log in after a number of attempts that are > > > appropriate in his opinion. > > > > > > The author could track this number himself but this way, it might be more > > > explicit that he is encouraged to think about the number of failures. > > > > Arguably the extension author could maintain that count as well, using the > > details as a dictionary into a map. I'm always hesitant to add additional > > parameters to the API if not needed. > > Ok, but then we should highlight this problem in the API documentation. SGTM.
	289 },

	290 { label: "onResponseStarted",

	291 event: "onResponseStarted",

	292 details: {

	293 url: getURLAuthRequired(),

	294 fromCache: false,

	295 statusCode: 200,

	296 ip: "127.0.0.1",

	297 responseHeadersExist: true,

	298 statusLine: "HTTP/1.1 200 OK",

	299 }

	300 },

	301 { label: "onCompleted",

	302 event: "onCompleted",

	303 details: {

	304 url: getURLAuthRequired(),

	305 fromCache: false,

	306 statusCode: 200,

	307 ip: "127.0.0.1",

	308 responseHeadersExist: true,

	309 statusLine: "HTTP/1.1 200 OK",

	310 }

	311 },

	312 ],

	313 [ // event order

	314 ["onBeforeRequest", "onBeforeSendHeaders", "onSendHeaders",

	315 "onHeadersReceived", "onAuthRequired", "onResponseStarted",

	316 "onCompleted"]

	317 ],

	318 {},

	319 ["responseHeaders", "blocking"]);

	320 navigateAndWait(getURLAuthRequired());

	321 },

	322 ]);

	323 </script>

OLD	NEW