Problem with browsers under Windows 7

[Lausebengel]

Hello ! I have a strange behavior with WSSE Authentication with this bundle. With Firefox and Chrome browser at Ubuntu operating-system every thing works fine. But If I try to access my Rest API with a browser under Windows (Firefox or Chrome - same version as under Ubuntu) I get "401 unauthorized" response.

Maybe someone has an idea where to look at to solve this ?

Thanks in advance.

[djoos]

Hi @oliver13,

would you be able to dig into the Symfony app's log to find out a bit more about the reason for the 401? Are you making use of different settings for the actual generation of the digest?

Thanks! David

[djoos]

Additionally: have a look at #37, perhaps writing some functional tests for your WSSE-secured API-calls will give you a good base...

FYI: I'll close this issue for now as it is out of scope of the actual bundle, but don't hesitate to comment on it so you can get up and running!

Kind regards, David

[Lausebengel]

Hello David,

thanks for your reply ! I'm still busy today. I will check this tomorrow and post my results here.

With kind regards Oliver

[Lausebengel]

Hello David,

I found in the app.log :

app.DEBUG: Future token detected

The Token is 3 seconds in the future : 1402489574 > 1402489571 Is there a best practice to handle different timestamp of client and server application ? Is it usefull to have some kind of buffer of some seconds / minutes ?

Thanks in advance, Oliver

[djoos]

Hi @oliver13,

so it seems your client is generating tokens that are in the future. The lifetime-setting will allow you to allow a buffer (default 300 seconds, but configurable in security.yml) before the provider will decide the expire timestamp is expired, but this is not related to future tokens and future tokens are not allowed.

If syncing the time between client and server (ntp?) is not an option, the provider can be extended so you can use a different rule for the isTokenFromFuture-method...

Do let me know how it goes, thanks in advance for your feedback!

Kind regards, David

[Lausebengel]

Hello David,

thank you for your answer. I get it to work by using the same timeserver (ntp.org) on the windows client as on my linux server :-)

Kind regards Oliver

[djoos]

Perfect, glad you're all up and running!

Kind regards, David

[Drusy]

Hello,

As a mobile developer I face the same problem that had @oliver13 few month ago. It can happen that the mobile is not perfectly synchronized to the server that run the WSSE authentication.

As the isTokenFromFuture is really strict, it becomes complicated to avoid the 401 on these devices and we are having many negative feedbacks. We don't want to use the HTTP header date from the server because we don't want to send a fake request only to get the server side perfect hour.

Do you have any valuable solution ? Would you consider a pull request to add some parameter as private $lifetime; but applied to isTokenFromFuture with a default 0 value ?

Thanks in advance.

[djoos]

Hi @Drusy,

thanks for reaching out!

If the isTokenFromFuture doesn't work for your use case, I'd suggest you to use a custom provider class, extending from the one in the bundle. Then you can override the isTokenFromFuture-method to make it do what you want for your specific use...

What do you think?

Kind regards, David

[Drusy]

Hi,

Actually it sounds really good for us, so we can override this behavior and keep your library up-to-date. Let me know if you want a PR for this behavior or if you implement it by yourself for some need.

Thanks for your work and quick answer. Kevin

[djoos]

Hi @Drusy,

thanks for your feedback! I think the methods in the provider are flexible enough for any specific use case to be implemented if needed. I don't think a lifetime for the isTokenFromFuture is needed...

Don't hesitate to get in touch if you have any further questions or remarks!

Kind regards, David

[parnas]

@djoos David, I don't think that you are correct that lifetime for the isTokenFromFuture is needed. Because this issue happens even with nap synced hosts. Time between systems doesn't have to be different in any human perceived intervals, if a requestor will just be few milliseconds ahead - that will already create future tokens from time to time.

Currently we are solving that with a custom provider, but I think that main library should allow for, at least, one second difference by default.

[djoos]

Hi @parnas,

thanks for your feedback!

I mentioned in my previous reply that I don't think a lifetime for the isTokenFromFuture is needed. So you think it is?

Don't hesitate to send over a PR or a gist with the custom provider you mentioned.

Thanks in advance for your feedback!

Kind regards, David

[ishakuta]

@djoos Hi, David, at least this:

protected function isTokenFromFuture($created)
{
    return strtotime($created) > self::FUTURE_SECONDS + strtotime($this->getCurrentTime());
}

But it's better to have it configurable via provider's constructor argument and configuration tree, if you agree to accept such PR - I can prepare it. So the default behaviour would remain the same, as you'd like, but will allow people like us to configure it as we wish.

Thanks.