2012-08-31 8 views
5

Anteriormente, cuando traté de hacer una llamada ajax a un ashx como una cuenta no superusuario (es decir, como usuario específico del portal), mi servidor web devolvía las cookies para borrar mi autorización. I posted a question about this y parecía que la respuesta era asegurarse de que el portalid=xx se haya especificado en mis parámetros GET.¿Por qué DotNetNuke me desconecta de las solicitudes de post jajax?

Sin embargo, acabo de descubrir que si agrego portalid=xx en una solicitud POST, DotNetNuke parece ignorar y cerrar la sesión de cualquier cuenta no superusuario.

¿Cómo puedo mantener la autorización durante las solicitudes DNN POST ajax?

Respuesta

0

He encontrado algunas cosas para que compruebe y vea si alguna de ellas resuelve su problema.

  • Asegúrese de estar utilizando un ScriptManagerProxy. Esto permite que las páginas ascx usen AJAX mientras que la página principal también usa AJAX.
  • Ha habido muchos informes de personas que no pueden ejecutar AJAX con DNN si la Persistencia de estado de página está establecida en "Memoria". Aquellos que experimentan esto han sido capaces de solucionarlo cambiando la Persistencia del estado de la página a "Página". La forma más sencilla de hacer esto es para ejecutar esta consulta:

    actualización HostSettings conjunto SettingValue = 'P' donde SettingName = 'PageStatePersister'

Después de ejecutar eso, usted necesita para reciclar la aplicación. Si no tiene acceso al servidor, simplemente agregue un espacio o retorno de carro a su archivo web.config (que obligará a la aplicación a reciclar).

  • Por último, puede ver si tiene esta línea en su web.config. A veces, la eliminación ayudará:

    <system.web> < xhtmlConformance mode = "legado"/> </system.web>

+0

¿Has tenido la oportunidad de ver estas posibles soluciones? – Joshua

+0

Lo sentimos, no hemos podido probar esto hasta hoy. Lamentablemente, ninguno de esos funciona. Probablemente también debería decir que no estoy usando ASP.NET Ajax, pero jquery para realizar mis publicaciones. – KallDrexx

1

creo que tengo un buen control sobre toda la situación y, desafortunadamente, parece que la única solución verdadera es asegurarse de que cada portal secundario tenga su propio subdominio en lugar de una suburl (por ejemplo, portal.domain.com en lugar de domain.com/portal).

El problema es que cuando su portal 0 es domain.com pero el portal 1 es domain.com/portal todo funciona correctamente hasta que necesite acceder a un archivo .ashx a través de ajax. Lo que sucede entonces es que la URL que se solicita es en su lugar domain.com/DesktopModules/MyModule/Handler.ashx, que no contiene el /portal/ en ella, lo que hace que DNN crea que está haciendo una solicitud en el portal 0 y cierre la sesión.

Si bien las solicitudes GET pueden superar esto con un parámetro portal=1, esto no parece funcionar para las solicitudes POST.

Por lo tanto, la mejor solución que parece es tener su portal en un subdominio distinto (portal.domain.com), y entonces no se arriesga a perderse algo como esto.

+0

Esta respuesta es probable en la vecindad correcta de cuál es el problema. Cualquier cierre de sesión suele deberse a una referencia de portal ambigua en la URL, lo que hace que la solicitud identifique incorrectamente el portal al que pertenece la solicitud. También es importante entender exactamente cuándo se produce el cierre de sesión. A veces se trata de un encuentro en el grupo general de solicitudes que entran en una vista de página, pero parece que se cierra la sesión de POST, cuando de hecho ya ha cerrado la sesión y no importa qué solicitud se realice a continuación. siempre dará como resultado una respuesta no autenticada. –

Cuestiones relacionadas