When getting the callback to /Account/ExternalLoginCallback the call to SignInManager.GetExternalLoginInfoAsync returns info just fine. The user then registers and the callback to /Account/ExternalLoginConfirmation is called and SignInManagerGetExternalLoginInfoAsync now returns null. The data isn't staying around for some reason.
If I look at requests through Fiddler, I can see in the call to /Account/ExternalLoginCallback that there is a cookie named Identity.External. When calling /Account/ExternalLoginConfirmation, that cookie is no longer there. I think this is the problem, but I have no clue why. In between these two calls there is a call for the /favicon.ico file that returns a 302 causing a call to /Account/Login?ReturnUrl=%2Ffavicon.ico. Both those calls still have the Identity.External cookie showing.
This just started happening and I can't figure out why.
Related
Right now we are storing the session in map. So very first time , when we create session, it is possible that the session got created ,but due to some issue ,it immediately disconnected and logged out.
After some time, being the sessionId present in map, we are calling just lookup for that session and call logOn() . It should call my overridden logon() method which is not happening. Can anyone tell me the the possible clause and how to handle this ?when I see the logs, it's showing EndOfStream occurred,disconnecting.
When using the GraphAPI's Delta Query for /users, we have noticed that the assignedPlans property is only returned on the first call to /delta, but on all subsequent calls that use the deltaLink returned on the previous call, the property is consistently missing.
The API call we make on the first call:
GET https://graph.microsoft.com/v1.0/users/delta?$select=id,mail,givenName,surname,userType,displayName,givenName,userPrincipalName,businessPhones,jobTitle,mobilePhone,officeLocation,department,companyName,assignedPlans
This call's response does include the assignedPlans property for users, but on subsequent calls (using the deltaLink) - this property is missing.
Is this a known issue with the Delta Query?
Thank you!
I've already searched via google and on stackoverflow, but could not find any similar problem to mine.
In my project I'm handling a ViewExpiredException properly and show a custom page to the user that the current session has timed out. This works great, but I want to do something BEFORE this message gets shown to the user. Actually I'm working with 2 different sessions here, one on the frontend side and one on the backend, so the idea is to NOT start a new backend session when the current one timed out.
Is there any possibility to fetch the ViewExpiredException while I'm inside the doFilter method, so I do not start a new backend session (simply because it is not needed)? Or is there any other way?
I already tried to fetch the current context via
FacesContext fc = FacesContext.getCurrentInstance();
But obviously the context is null, because the session timed out.
Inside the ExceptionHandlerWrapper I have access to the UnhandledExceptionQueuedEvents, but this does not help me here since I need this information earlier.
I hope I made my problem clear enough.
Thanks in advance for any help!
Regards
Sebastian
Generally ViewExpiredException is thrown when a POST request is fired while the session is timed out. So, this should do in the filter:
boolean post = "POST".equals(request.getMethod());
boolean timedout = request.getRequestedSessionId() != null && !request.isRequestedSessionIdValid();
if (post && timedout) {
// JSF will guaranteed throw ViewExpiredException when state saving is set to server.
}
But this does not cover all possible cases. ViewExpiredException can also occur when the session hasn't timed out. For example, when the client has passed an invalid javax.faces.ViewState parameter, or when the associated view has been pruned from the LRU map which can by default hold 15 views. This is however not detectable inside a servlet filter before FilterChain#doFilter() is called. You really need to be inside the JSF context. You could do the backend session creating job in a PhaseListener. E.g. in beforephase of apply request values phase, which is guaranteed to be invoked only when there's a vaild view.
By the way, the FacesContext is not null in the filter because the session has timed out, but because the FacesServlet, the one responsible for creating it, hasn't been invoked yet at that point. You know, filters run before servlets.
I have a working prototype implementation of the Quickbooks Web Connector (QBWC) interface. Everything works as expected except that the closeConnection method is not getting called most of the time.
Expected Behavior
The QuickBooks Web Connector Programmer’s Guide states the following (pg. 21):
What happens when QBWC gets this string array? If the second member of
the string array contains “none” or “nvu”, QBWC will display a
message, call closeConnection, and stop the session.
Also, the Guide indicates the same info in the "clientVersion and authenticate callbacks" illustration (Figure 2-2, pg. 20):
Call authenticate
If return is "none" or "nvu",
Display message, call closeConnection and stop
Actual Behavior
When the authenticate method returns a value of "none", these (and only these) web methods are called (in the order listed):
serverVersion
clientVersion
authenticate
Note that this is only when there is no work available for QBWC/Quickbooks. When there is work, the authenticate web method returns an empty string and QBWC subsequently calls the following web methods:
sendRequestXml
receiveResponseXml
closeConnection
EDIT 1: After forcing the clientVersion web method to return an "E" result, it does halt the update process as documented in the Programmer's Guide but the closeConnection web method is not called under these circumstances either. It's interesting to note that QBWC does still call the serverVersion web method after the clientVersion returns an "E" result.
Troubleshooting Efforts
Verified (through tracing) that the second member of the string array does in fact contain a value of "none". However, the closeConnection callback never fires for that session.
Double-checked the QBWC client log (QWCLog.txt) and find no mention of closeConnection being called and consequently no errors related to such a call.
Verified that the method code used for closeConnection is identical to the example found in the Programmer's Guide (pg. 68).
Supporting Info
For what it's worth, here are a few details of the implementation.
ASP.Net 3.5 (c#)
QBWC 2.0.0.139
Does anyone know more about this problem with CreateResponse?
public HttpResponseMessage GetProductLine(Guid id)
{ ... // get object etc. //
// This works.
return this.Request.CreateResponse(HttpStatusCode.OK, productLine);
// This causes HTTP 500 Internal Server Error.
return this.Request.CreateResponse(HttpStatusCode.OK, (EntityObject)productLine);
It creates the response but something goes wrong when it is returned, so within the Web API framework.
I discovered this because I have a base API controller in which I have my own CreateResponse method which calls this.Request.CreateResponse as per above, then adds a few headers and writes some logging to the response and hands it back.
What's particularly interesting is that this works for one of my entity controllers, and not for this latest one - i.e. it just doesn't like some entities.
I can solve it by making my implementation look like this:
MyBaseApiController.CreateResponse<T>(HttpStatusCode statusCode, T entity)
where T : EntityObject
But nevertheless, it is odd.
UPDATE
Due to some DRY refactoring, my previous fix is broken. I cannot figure out how to con it into working again, so I'm stuck.
The problem does not seem to occur when returning objects from the database but when I return an object that has been received in a Put.
The problem also occurs when building my own HttpResponseMessage manually and setting the formatters.
I'll have to re-read the data from the database before returning it and hope that works - my Get is fine, so it should do.
UPDATE 2
Oh that's insane. Even if I get the object again from EF and return it using the same line of code as in my Get handler/action, it fails. The difference now must be in the requests - the GET formed by Chrome is fine, the PUT formed by my test client (JSON) must be tripping it up.
UPDATE 3
I spent the day flattening out my entities to avoid any inheritence and the problem has gone. Inheritence is a no no, it seems.
UPDATE 4
So I have a new WebAPI service which is returning a serializable class I've written. Although it can be serialized using the DataContractSerializer, when my request accepts XML I get a 500 but its fine when I accept JSON.
UPDATE 5
Using an ITraceWriter I've managed to see the stacktrace, which ends like this:
Exception.Source: System.Xml Exception.Message: '', hexadecimal value
0x05, is an invalid character. Exception.StackTrace: at
System.Xml.XmlUtf8RawTextWriter.InvalidXmlChar(Int32 ch, Byte* pDst,
Boolean entitize)
Looks like some byte arrays in the object are screwing with the Xml formatter/serializer.