I have had problems getting PHP session variables (e.g. $_SESSION['username']) to work within PHP server side code launched via an ajax call from a Phonegap app.
On researching this problem I have found conflicting advice as to whether or not session variables and cookies can be used.
Does anyone have a definitive answer?
If session variables and cookies can be used are there any issues I should be aware of in using them that may have contributed to them not working?
I know that cookies can be enabled for Phonegap apps on an iPhone but as far as I am aware not for Android.
You would be better off passing the data you would normally store in the session variables to your PhoneGap app via JSON and having the app store it that way.
Think of it like using an external API. The app would authenticate and get back a token. It would store that token and use that to validate further requests to the server were authenticated.
Related
I'm kinda lost.
I see A LOT of TokenMismatchException exceptions in my production logs and all of them came from android devices (I log the useragent, ip, url and request method with every exception)
It's basically a simple landing page with form so I see no reason people might be on page for few hours (that'll cause session expiration). I also pass the XSEF-TOKEN cookie content using the X-XSRF-TOKEN header so this is shouldn't the problem
I tried using my iPhone and everything worked with: Safari (both private and regular modes), Chrome and Facebook inline browser
I also tried using my girlfriend's LG G4 using Chrome, Built in android browser and Facebook inline browser and it worked as well.
I temporarily disabled the csrf middleware for this specific route so people won't get errors but this can be really bad. So what should I do next?
I'm using Laravel 5.2, sessions driver is file (cannot do redis from the server the client gave me) and the sessions directory is writable. Lots of sessions are in the directory so this is not a permissions problem. PHP version is 6.5.18.
Thanks !
I have an application hosted in Azure using Azure Active Directory and OpenIDConnect for authentication - generally all works well. However I'm having an issue where some requests generate a call to https://login.microsoftonline.com/ and then on to the requested page - no password is requested. I'm assuming that this is some kind of token refresh?
The problem is that the site uses a fair amount of ajax and these requests stop working because they get redirected to https://login.microsoftonline.com/ This happens after maybe 15 minutes, however the nbf and exp properties of the JWT token show a validity period of approximately an hour.
I've set the BackchannelTimeout property of OpenIdConnectAuthenticationOptions to 30 minutes, however this doesn't seem to have made any difference.
Can anyone offer any advice on what may be happening and the options to change or work around the behaviour?
Your question can be answered in the same way as this other thread: MVC AD Azure Refresh Token via ADAL JavaScript Ajax and KnockoutJs
In short: the OpenId Connect middleware is designed to support redirect based web applications. Ajax calls are not well suited to be protected via cookies, and the issue you are experiencing is one of the reasons why. Javascript based API calls are better protected using tokens rather than cookies.
For some links that might provide an alternative approach, see the link above.
I created a nuget package for .NET web applications which is refreshing the Azure Active Directory Token in the background.
More info: https://www.nuget.org/packages/RefreshTokenForAjaxRequest.Azure.ActiveDirectory/
I need to authenticate to JIRA using Okta via REST, how can I do that on ruby? It is possible? I never did that before, I just only want to get an attached file from a ticket in JIRA
It turns out that you can just send the JSESSIONID cookie from a logged-in user (such as yourself) to the REST API. You can get the cookie manually from the browser, or write a browser extension to get the cookie and then invoke your Ruby script with that cookie's value as a command-line argument. For Chrome, you could use Chrome Native Messaging for this.
You should be able to do it by setting up an Application Link to a ruby web application with 2-way OAuth, but this is quite complicated and heavyweight.
I would like to figure out a way to do it with just basic auth and no Application Link, but I haven't figured out how to yet.
I have created a REST API for an android application. There are certain req.session variables that I set at certain points and use them in the policies for further steps. Everything works fine when I access the API from a REST client like POSTMAN.
However, when it is accessed from a native android app, the req.session values that I set in one step are lost in the next step.
Any idea why this might be happening and what might be the workaround ?
Session does not work with request sent from untrusted client (in this case the Android device).
You should consider using the OAuth strategy to accomplish your target. It's a bit complicated.
Or just simply generate an accessToken for each successful login then return it to the client. For further requests, the client must attach this accessToken (usually to the header) of the requests.
This is a good SO question for the same issue: How to implement a secure REST API with node.js
I am building a small web application and in my application I am using the session object to store information across calls to server. This works quite fine in Firefox \ Chrome\ IE, but it seems to fail in Safari. In Safari the session keeps forgetting that I've stored values in it.
Why is this happening? what can be done?
The session is based on an id stored in a cookie. The server uses this Id to link to your session on the server. It's highly likely cookies are off here. Load up fiddler or turn on tracing to see what cookies are being sent over... You should see the one with aspnetsessionid in it, if not your browser prob has them turned off.
You may also want to take a look over here: Facebook API and Safari
Looks like, if any redirect is sent when you are establishing cookies, they will be viewed as 3rd party cookies and could cause issues with your server-side.
if your settings on Safari are set to not allow cookies, then this fails. I have just had the same issue on an iphone web app im writing. I enabled cookies and all worked fine.
The whole idea of the Session is that the values are stored server-side. Safari can't possibly cause the server to forget something. Either the value wasn't ever stored in the Session or Safari is failing to render the Session value.
Trying using a debugger to confirm if the Session holds the correct value when passing the value into the Session and when you're attempting to retrieve the value from the Session.